2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00500.txt

Text File | 1994-06-10 | 726.3 KB | 16,939 lines

[ Last modified 23 January 89 - Ken van Wyk ]

Welcome!  This is the  semi-monthly introduction posting   to VIRUS-L,
primarily for the benefit of any newcomers  to the list.   Many of you
have probably already seen  a message (or two...)  much like this, but
it does change from time to time, so I would appreciate it if you took
a couple of minutes to glance over it.



What is VIRUS-L?

It is an electronic mail discussion forum for sharing  information and
ideas about computer  viruses.  Discussions should include   (but  not
necessarily  be limited to): current  events  (virus sightings), virus
prevention    (practical  and   theoretical),    and  virus    related
questions/answers.   The list  is moderated  and digested.  That means
that  any message coming  in gets  sent  to  me,  the  editor.  I read
through the messages and make sure  that they adhere to the guidelines
of the list (see below) and add them to the  next digest.  Weekly logs
of digests are kept by the LISTSERV (see below  for  details on how to
get them).  For  those interested in statistics,  VIRUS-L is now (Jan.
23, 1989) up to 950  direct subscribers.  Of  those, approximately  80
are local redistribution accounts with an unknown number of readers.

As stated above, the list is digested and moderated.  As such, digests
go out when a) there are enough messages for  a digest, and  b) when I
put all incoming (relevant) messages into the digest.  Obviously, this
can   decrease   the  timeliness of urgent    messages such  as  virus
warnings/alerts.  For that, we have a sister list called VALERT-L.  It
is unmoderated  and undigested  - anything  going in  to the list goes
directly  out  to  all  the  subscribers, as  well  as  to VIRUS-L for
inclusion in the  next available  digest.   VALERT-L is for  the  sole
purpose of  rapidly sending out  virus alerts.   Anyone who  does  not
adhere to this  one guideline of  VALERT-L will be immediately removed
from the list.   That is, no news   is good  news.  Subscriptions  and
deletions to  VALERT-L are  handled identically as  those  for VIRUS-L
(see instructions below).


What VIRUS-L is *NOT*?

A place to  spread hype about  computer  viruses;  we already have the
Press for that.  :-) A place to sell things, to panhandle, or to flame
other subscribers.  If anyone *REALLY* feels the need to flame someone
else for something that they may have  said, then the flame  should be
sent directly to that person and/or to the list moderator  (that would
be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you are  reading this, chances are *real  good* that  you are
already on the list.  However, perhaps this  document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB  VIRUS-L your name.  LISTSERV  is a
program which automates mailing lists such as VIRUS-L.  As long as you
are either on BITNET, or any network accessible to BITNET via gateway,
this  should work.  Within  a short time, you will  be  placed  on the
mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in  the unlikely  event, you should  happen  to want to be removed
from  the   VIRUS-L     discussion    list,   just    send   mail   to
<[e-mail]>  saying  SIGNOFF VIRUS-L.   People, such as
students, whose accounts are going to be closed (for example, over the
summer...) - PLEASE signoff of  the list before  you leave.  Also,  be
sure to send your signoff request to the LISTSERV and  not to the list
itself.  Note that the appropriate node  name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail  to  <[e-mail]>  and it  will
automatically be sent to the editor for possible inclusion in the next
digest to go out.


What does VIRUS-L have to offer?

All  VIRUS-L  digests  are stored in  weekly   log  files which can be
downloaded by  any user on  (or off) the mailing  list.  Note that the
log files contain all of the digests from a particular week.  There is
also a small archive  of some of the  public anti-virus programs which
are currently available.  This  archive, too,  can be accessed  by any
user.  All  of this is  handled automatically by the  LISTSERV here at
Lehigh University (<[e-mail]>).


How do I get files (including log files) from the LISTSERV?

Well, you will first want  to know what  files are   available on  the
LISTSERV.  To do this, send mail  to <[e-mail]> saying
INDEX VIRUS-L.   Note   that filenames/extensions  are  separated by a
space, and not by a period.  Once  you  have decided which file(s) you
want,  send   mail to  <[e-mail]> saying  GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the  file called
VIRUS-L LOG8804 (which happens to be the  monthly  log of all messages
sent to VIRUS-L during   April,  1988).  Note  that, starting  June 6,
1988, the logs  are weekly.  The  new file format is  VIRUS-L LOGyymmx
where yy is  the year  (88, 89, etc.),  mm is the  month, and x is the
week (A, B, etc.).  Readers who prefer digest format lists should read
the  weekly logs  and sign   off   of   the  list  itself.  Subsequent
submissions to the list should be sent to me for forwarding.

Also available is a  LISTSERV at SCFVM which  contains more anti-virus
software.   This  LISTSERV  can  be  accessed  in  the  same manner as
outlined   above,   with  the    exceptions  that    the  address   is
<[e-mail]> and that the commands to  use are INDEX PUBLIC
and GET filename filetype PUBLIC.


What is uuencode/uudecode, and why might I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back  again.  This  is so binary  files can  be
easily transferred via  electronic mail.  Many  of  the files on  this
LISTSERV  are binary files  which are stored in uuencoded  format (the
file types will be  UUE).  Both uuencode  and  uudecode  are available
from the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal
here.  Uuencode is available in Turbo  Pascal.  Also, there  is a very
good binary-only uuencode/uudecode  package on the LISTSERV  which  is
stored in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus  discussions.   This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.



What are the guidelines?

     Try to keep messages relatively short and to the  point, but with
     all relevant information included.   This serves a  dual purpose;
     it keeps network traffic to  a necessary minimum, and it improves
     the likelihood of readers reading your entire  message.

     Personal information and  .signatures  should   be  kept to   the
     generally accepted maximum of 5   lines of text.  The editor  may
     opt  to shorten  some lengthy   signatures (without deleting  any
     relevant  information, of course).  Within   those  5 lines, feel
     free to be a bit, er, creative if you wish.

     Anyone  sending  messages   containing, for  example,   technical
     information should   *PLEASE*  try  to  confirm their  sources of
     information.  When possible, site  these sources.  Speculating is
     frowned upon -  it merely  adds confusion.  This editor does  not
     have the time to confirm all contributions  to  the list, and may
     opt to discard messages which do not appear to have valid sources
     of information.

     All messages sent  to  the list  should have appropriate  subject
     lines.  The subject lines should  include the type of computer to
     which the message  refers, when applicable.  E.g., Subject: Brain
     virus detection (PC).  Messages without appropriate subject lines
     *STAND A GOOD CHANCE OF NOT BEING INCLUDED IN A DIGEST*.

     As already  stated, there will  be no flames  on the list.   Such
     messages will be discarded.

     The same goes for any commercial plugs or panhandling.

     Submissions  should be directly   or indirectly   related  to the
     subject of computer viruses.  This one is particularly important,
     other subscribers really  do not want to  read  about things that
     are  not  relevant  -    it only  adds to  network    traffic and
     frustration for the people reading the list.

     Responses to queries should be sent  to the author of  the query,
     not to the entire list.  The author should then send a summary of
     his/her responses to the list at a later date.

     "Automatic  answering machine" programs (the ones  which reply to
     e-mail for you when you are gone) should be set to *NOT* reply to
     VIRUS-L.  Such  responses sent to  the entire list are  very rude
     and will be treated as such.

     When sending in a submission, try  to see whether or  not someone
     else  may have just said  the same  thing.   This is particularly
     important when  responding to postings   from someone else (which
     should be sent to that person *anyway*).  Redundant messages will
     be sent back to their author(s).

Thank-you for your time  and for your  adherence to these  guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.


Ken van WykVIRUS-L Digest   Wednesday,  1 Nov 1989    Volume 2 : Issue 229

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

re: Virus scanning on PCs?
Re: Protection in Operating Systems
re: Where are the Sophisticated Viruses?
re: Self-checking programs (PC)
Re: Virus source available in Toronto
Re: Self-checking programs (PC)
Supplemental Security Info on DECnet Worm (VAX/DECnet)
Re: Checksum programs
Re: Imbedded virus detection
Re: Checksum programs

---------------------------------------------------------------------------

Date:    31 Oct 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Virus scanning on PCs?

> Do scanning programs (in particular scanv45) check video memory
> for a virus?

Once again, it's important to remember that a virus has to get
itself -executed- somehow.   That means altering some object
that gets executed (typically EXE and COM files and boot
sectors so far).   Nothing that I know of will execute code
found in video memory.   So a virus, even if it did hide most
of itself in the video memory, would have to change some
executable object (COM or EXE file, boot record, etc) in order
to get executed.   So, if you can check your executable
objects thoroughly enough, it's not necessary to check
video memory as well.   All the known viruses hide in
EXE or COM files, or boot records, so those are the only
things any scanner for known viruses has to check.  (This is
about the same answer I gave last week to the question about
viruses "hiding" in sectors marked as bad.)                    DC

------------------------------

Date:    31 Oct 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Protection in Operating Systems

Bill Davidsen's point that DOS allows all sorts of things that
UNIX(tm) doesn't is quite true.   Remember, though, that viruses
don't *have* to do any of those things (write over the o/s
in memory, write directly to the hardware, etc) in order to
spread.   See Cohen's "Computer Viruses - Theory and Experiments"
paper for some quite convincing numbers about viruses and
UNIX.   *Any* operating system that allows users to write
programs and share information will be vulnerable to viruses.   DC

------------------------------

Date:    31 Oct 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Where are the Sophisticated Viruses?

You're forgetting one important kind of virus detector: a
general modification-detector that does a check-code of some
kind (CRC, MDC, or whatever), and alerts the user when
a file's *contents* (not the date) change.   There are
enough people using such things (at least in the PC world;
I don't know much about that Mac world) that I think even
a virus that talked straight to the hardware to avoid
"suspicious activity" detectors wouldn't get far before
it was detected.                        DC

------------------------------

Date:    31 Oct 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Self-checking programs (PC anti-virus protection)

> The basic idea is OK, but you need to use a "one-way" hash function,
> rather than something readily invertible like a linear CRC.

John Sangster is basically correct, but I'd like to suggest that
it's possible to get the advantages of a CRC (faster and more
exportable than the DES), and still avoid invertibility.  The
key (hehe) is that a CRC is easily invertible only if you know
the polynomial used.   If a modification-detector were to use
a different CRC polynomial for each user (based, for instance,
on a key phrase elicited from the user at each run), and the
database of CRCs were kept from the virus (to avoid the virus
being able to calculate the polynomial from file-CRC pairs),
the theoretical invertibility of the CRC wouldn't matter,
because a virus would not have all the information needed
to make an undetected change.

DC

------------------------------

Date:    31 Oct 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Virus source available in Toronto

>        however "Viruses , A high Tech disease" published only
> overwriting viruses!!

Hm, maybe there are two versions of the book?   The one I have
contains an almost-complete disassembly of the 648 (aka Vienna,
DOS-62, etc) virus on pages 156-164.   This virus is a standard
(very small) non-overwriting virus, that spreads between COM files,
and leaves the function of the infected program intact.

DC

------------------------------

Date:    31 Oct 89 12:54:19 +0000
From:    [e-mail] (Leif Andrew Rump)
Subject: Re: Self-checking programs (PC anti-virus protection)

[e-mail] writes:
>               ... this product includes an "INSTALL" utility which
>"vaccinates" the boot track and all executables on the disk.
>"Vaccination" consists of appending a cryptographic "seal" checking
>module (smaller than a typical virus!)  and patching the load module
                                             ^^^^^^^^
>header so that this module executes first, then passes control to the
>original application program if the program is "clean", otherwise
>halting and issuing a warning message.

If a virus killer can patch a program so can a virus! Exactly as virus
detectors is able to find a virus by looking at the code so is the
virus able to detect the virus killer and disable it! That's life!!

  Leif Andrew Rump, AmbraSoft A/S, Roejelskaer 15, DK-2840 Holte, Denmark
 UUCP: [e-mail], phone: [phone], touch phone: [phone]+313

   > > > Why are tall Irish girls with red hair so wonderful ? ? ? < < <



------------------------------

Date:    Tue, 31 Oct 89 16:38:58 -0500
From:    [e-mail] (SPAN SECURITY MGR. [phone])
Subject: Supplemental Security Info on DECnet Worm (VAX/DECnet)


NETWORK SECURITY SUPPLEMENTAL INFORMATION - PROTECTING THE DECNET ACCOUNT

The most important thing that needs to be done to protect a system
against the current WORM attacks is to modify accounts where
USERNAME=PASSWORD.  This is the default configuration for the DECNET
account.  This can be changed easily, but there appears to be some
confusion about the effect that this has on a network. Changing the
DECnet default password DOES NOT IMPACT the normal operation of DECnet
in any way.
                            --------

The following section provides some background material to illustrate
this point:

On your system, issue the following commands from a priviliged
(CMKRNL,BYPASS,SYSPRV) account:

        $MCR NCP (or $RUN SYS$SYSTEM:NCP)
        NCP> show executor characteristics

This will produce a list that resembles the following:


        Node Volatile Characteristics as of 31-OCT-1989 11:02:23

        Executor node = 6.133 (NSSDCA)

        Identification           = DECnet-VAX V4.7,  VMS V4.7
        .
        .
        .
        Nonprivileged user id    = DECNET
        Nonprivileged password   = DECNET
        .
        .
        .

This is your DECnet executor database.  The information listed is the
default configuration for your node.  The information contained in this
list includes "Nonprivileged user id" and "Nonpriviliged Password".

This information is what DECnet uses for userid/password when the
connecting process a)does not have a proxy, b)does not specify a
username/password as part of the access string, and c)does not
have a different userid/password defined for the network object
being invoked.

The access information contained in the executor database is used for
reference only. The candidate userid and password (in this case DECNET
and DECNET respectively) are then passed to LOGINOUT to validate them
against the *REAL* information contained in SYSUAF.DAT.  If the
information matches, the access is allowed. If the information does not
match, the connecting user gets the following error messages:

         Unable to connect to listner
         Login Information Invalid at Remote Node

                          --------

In order to correctly change your default network password so that your
system cannot be easily exploited by the current DECnet WORM, the
following 2 steps must be followed:

1)  Change the password for user DECNET in SYSUAF.DAT:

        UAF> modify DECNET/Password=NEW_DECNET_PASSWORD

                               *NOTE*
           It is advisable at this time to check that
           certain other attributes of the DECNET user
           are properly set:

           The ONLY access method for this account should
           be NETWORK. The BATCH, REMOTE, INTERACTIVE,
           and DIALUP fields should all read "--no access--"

           The value of PRCLM should be set to ZERO. This is
           the number of (SPAWNed) sub-processes allowed.

           The flag LOCKPWD should be set. This prevents
           anyone but a priviliged user from changing the
           password. The following command can be used:

      UAF> MOD DECNET/FLAGS=LOCKPWD/PRCLM=0/NOBATCH/NODIAL/NOINTER/NOREM/NETW


2) Change the password for DECNET in your network executor database:

        NCP> set exec nonpriviliged password NEW_DECNET_PASSWORD
        NCP> define exec nonpriviliged password NEW_DECNET_PASSWORD

The important thing to remember is that the password must be changed in
BOTH places, otherwise your network WILL break.  The worm is breaking
nodes by penetrating the DECNET account, and changing only the UAF
password with the $SET PASSWORD command.  By not changing the NCP
password, the network no longer accepts INBOUND connections.

For more information, consult the VAX/VMS manuals:

   VMS V4.X - Volume 6 "Networking Manual"
   VMS V5.x - Volume 5A&5B "Guide to DECnet-VAX Networking"
- ---------------------------------------------------------------------------
Ron Tencati                           |   NCF::TENCATI /6277::TENCATI
SPAN Security Manager                 |   [e-mail]
NASA/Goddard Space Flight Center      |   [phone]
Greenbelt, MD. USA                    |
- ---------------------------------------------------------------------------

------------------------------

Date:    31 Oct 89 20:54:37 +0000
From:    [e-mail] (Paul Kerchen)
Subject: Re: Checksum programs


[e-mail] (Y. Radai) writes:

>  In my opinion, the most important requirements on a checksum program
>are:
>(5) It must be convenient to specify and update the list of files to
>    be checksummed.

This point brings up a problem which is common to most checksumming
solutions: where does one store these checksums and their keys?  If
they are stored on disk, they are vulnerable to attack just like
programs.  That is, a virus could infect the program and then update
its checksum, since the key must be somewhere on disk as well (unless
the user enters it every time they compute a checksum--yecch!) and one
must assume that the checksum algorithm is known.  Or,
more simply, a virus could simply wipe out all the checksums,
leaving the user to decide which files were infected.  Storing the
'sums off line would insure security, but at what cost?  Checking
and updating the 'sums with any frequency would become tedious at best.
I don't mean to rain on this parade, but this issue is one which must
be considered by anyone writing a checksum-based anti-viral program.

Paul Kerchen                            | [e-mail]

------------------------------

Date:    Wed, 01 Nov 89 09:32:37 -0500
From:    [e-mail]
Subject: Re: Imbedded virus detection

Bob McCabe writes:
>  While working out the algorithm for this check it struck me
>that it should be possible to work out a scheme by which any
>program could check itself at load time for infection.

Have a look at PC Magazine Aug. 1989, 8(14), p411.  There is
some code there which does exactly this.
- --
Chris Owen                            | [e-mail]
Library                               | phone:  [phone]
Queensland University of Technology   | fax:    [phone]
Brisbane, AUSTRALIA                   |

------------------------------

Date: 1 Nov 89 13:47:43 GMT
From: comcon![e-mail] (Roy M. Silvernail)
Subject: Re: Checksum programs

[e-mail] (Y. Radai) writes:

>   In my opinion, the most important requirements on a checksum program
> are:
> (2) Even if the checksum algorithm and checksum length are known,
>     without knowledge of the key (the generating polynomial in the
>     case of a CRC algorithm), it should be impossible to modify a file
>     in such a way that the checksum remains unchanged.

What about doing both an 8-bit and a 16-bit CRC on the file, along with
a record of the file length? It seems to me that an altered file might
be able to duplicate one of the checksum, but not both, and certainly
not both sums *and* the length record. (This might also reduce the need
for each machine generating a unique checksum... something I have no
clue about. How would this be done?)

Roy M. Silvernail | UUCP: uunet!comcon!roy  |  "No, I don't live in an igloo!"
[ah, but it's my account... of course I opine!]           -Sourdough's riposte
SnailMail: P.O. Box 210856, Anchorage, Alaska, 99521-0856, U.S.A., Earth, etc.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  3 Nov 1989    Volume 2 : Issue 230

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

CRC checking
Re: Checksum programs
Re: Self-checking programs (PC)
Re:Virus source available in Toronto
DBASE Virus and SCANV47 (PC)
decompiling a virus

---------------------------------------------------------------------------

Date:    Wed, 01 Nov 89 00:00:00 +0000
From:    "Prof Arthur I. Larky" <[e-mail]>
Subject: CRC checking

             A CRC will work if you:

             (1) Keep the polynomial secret and personal.

             (2)   Keep   the  comparison  information  secret  and
             personal.

             You can accomplish (1) by having the checker  ask  for  the
        polynomial  (or  some  portion of it) when you boot up and start
        the checking.  The checker should NOT store  the  polynomial  on
        disk anywhere.

             You  can  accomplish  (2) by having the checker ask for the
        check file name and/or path when  you  boot  up  and  start  the
        checking.

             Both  of  these  are a pain to do, but losing everything on
        your hard drive is much more of a pain.  Of course,  you  should
        still do regular backups (I do lots of program development, so I
        back  up  everything  on floppy as soon as I create it) and have
        someone's program watching your disk for you.

             The basic rule  is:  Be  Different!   MSDOS  is  vulnerable
        because  it is so well-known how to write lethal things to disk.
        If you name your checksum file "Checksum.fil", you  are  looking
        for  trouble!   I know I can find a name and a sub-directory for
        it that I wouldn't recognize a month later.

                                      Art
                                   CSEE Dept
                               Lehigh University
                                 Bethlehem, PA


        Disclaimer, disclaimer, disclaimer

------------------------------

Date:    01 Nov 89 20:53:10 +0000
From:    [e-mail] (Leonard P Levine)
Subject: Re: Checksum programs

[e-mail] (Paul Kerchen) writes:
> This point brings up a problem which is common to most checksumming
> solutions: where does one store these checksums and their keys?  If
> they are stored on disk, they are vulnerable to attack just like
> programs.  That is, a virus could infect the program and then update
> its checksum, since the key must be somewhere on disk as well (unless
> the user enters it every time they compute a checksum--yecch!) and one
> must assume that the checksum algorithm is known.

The checksum program and the checksum should be stored in a place that is
different on each machine.  Furthermore, there is no special "best"
crc or testing algorithm, many will do with varying polynomials.

A satisfactory system is one in which each user can use a polynomial
of his/her choice and where the list of files and their crc's
(for example) is stored in some arbitrary location.  No virus writer
will be looking for YOU, rather just a collection of systems that
are alike enough to infect.

When dutch elm disease comes around, you should look like an oak tree.
Be different enough so that only a specific attack can defeat your
defences, not just some attempt to infiltrate command.com.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              FAX    [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:    02 Nov 89 02:02:35 +0000
From:    [e-mail] (Andrew P. Berman)
Subject: Re: Self-checking programs (PC anti-virus protection)

In article <[e-mail]> [e-mail] (Leif Andrew
Rump) writes:
>If a virus killer can patch a program so can a virus! Exactly as virus
>detectors is able to find a virus by looking at the code so is the
>virus able to detect the virus killer and disable it! That's life!!

I wonder if that's actually the case.  Consider that most of the virus'
created so far have been under 3 kilobytes.  A virus must be somewhat
small to avoid detection- a 40k patch to every program could be detected
visually by the user with a 1 meg floppy disk.  Perhaps a very complex
virus killer could patch a program in such a way that only a very complex
virus could unpatch it-  a patching algorithm X with a proof on the order of
"patch algorithm X cannot be unpatched by a program with less than 100k" or
something like that might do some good.
  Or, perhaps we could design patches that might be unpatchable by a
short virus, but would take a great deal of time. We're not really too
concerned about length of time it takes to patch, since that only would
occur once for each program.  Thus, a patching algorithm X which can
be proven to be computationally-hard to unpatch would be effective because
the virus might be required to take up a great deal of computer time,
again providing a means to alert the user.

Frankly, I find the stuff fascinating... I think there's some
theoretical computing issues involved here, but hey, what do I know, I'm
only a grad student.


Andrew P. Berman
[e-mail]

------------------------------

Date:    Thu, 02 Nov 89 18:47:07 +0100
From:    fbihh![e-mail] (Morton Swimmer)
Subject: Re:Virus source available in Toronto

[e-mail] (Kelly Goen) writes:

>Yes it is indeed true that viral sources are published in several
>areas... however "Viruses , A high Tech disease" published only
>overwriting viruses!! more similar to a logic bomb as when they infect
>the target executable the file is immediately destroyed(VERY EASY to
>detect) by the overwriting process. However any COMPETANT Assembly
>coder can manufacture far more unobtrusive viruses if he just thinks
>about it!! the published sources working or non working are really not
>that much of a threat...

Oh yes they are!
It is very much easier to start from a working source
than to start from scratch. Irrespective if you are
"competant" or not. Just take the source, think of
something and implement it. It will take you far less
time, and the inhibition is far less. This is exactly
what happened to one of the viruses published in
R**** B*****'s book. Not long afterwards, presto! we
had the Vienna (648) virus!
Granted, its just a small chip off the block, but
you must try everything to win this war.

Cheers, Morton

------------------------------

Date:    Thu, 02 Nov 89 15:09:50 -0800
From:    portal!cup.portal.com![e-mail]
Subject: DBASE Virus and SCANV47 (PC)

        A number of folks have looked at the DBASE virus (Ross
Greenberg's discovery), including Joe Hirst, Steffan Campbell and T.B.
Allen, and the general consensus is that the virus is very similar in
style to the TYPO virus (The COM version).  If the author of these two
viruses is one and the same person, then perhaps the DBASE author has
not completely been "re-habilitated" as Ross Greenberg has suggested.
If this is the case, then the DBASE virus may have been placed into
the public domain (and would indeed account for the inexplicable DBASE
problem reports that have been received over many months by the CVIA).
Accordingly, SCAN V47 has been updated to include a check for this
virus.  Better safe than sorry.

Alan

------------------------------

Date:    Thu, 02 Nov 89 22:30:19 -0800
From:    ames!dhw68k.cts.com![e-mail] (Rick 'Transputer' Stein)
Subject: decompiling a virus

I just finished reading "With Microscope and Tweezers: An Analysis of
the Internet Virus of Nov. 1988" by Eichin and Rochlis in the
Proceedings of the 1989 IEEE Symposium on Security and Privacy.  They
discuss the decompilation process but only in a vague sense.  What is
decompilation?

Do you actually have to take apart a core dump, find the opcodes,
operands, and build a hi-level pseudocode from this?  Is there an
automated tool, or hunk of software which decompiles images for you?
How do you detect a virus in core with a "process interagator" if
something like this exists.

- --rick

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  3 Nov 1989    Volume 2 : Issue 231

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Brain Virus info needed (PC)
Jerusalem Virus (PC)
Re: Checksum programs
WANK Antidote (VAX/VMS/DECnet)
Virus Invasion of Hardware?
Macintosh Virus List (Mac)
Identify Ashar Virus
re: VGA2CGA infected with virus? (PC)

---------------------------------------------------------------------------

Date:    Fri, 03 Nov 89 10:01:04 -0600
From:    Mitch Cottrell <[e-mail]>
Subject: Brain Virus info needed (PC)

Help Help Help

We have been infected with two virus strains...  Jeruslum-B and
Pakastani Brain...  I have gotten some information on Jeruslium...
but have not been able to get any info on brain other than how it
replicates itself..  I still dont know what system damage it can do
other than eat up a couple sectors of disk space.  Please let me know
if you have any info on this virus or a source for info.  ps.  I have
already tried McAfee Associates BBS.

Thanks...
Acknowledge-To: <C2852@UMRVMB>

------------------------------

Date:    Fri, 03 Nov 89 24:41:00 -0500
From:    "Chris_C.Conner" <[e-mail]>
Subject: Jerusalem Virus (PC)

The computers(PC) in many of the labs on campus(MSU) have been struck
by the Jerusalem Virus.  I used SCAN.EXE (I don't know what version)
and identified it as the Jerusalem Virus.  Irealize there have been
quite a few articles about it in the recent digests, but thinking I
was not susceptible, I didn't bother reading any of them.  Could
someone please send me any information on what the virus does, what I
can do to get rid of it, and any other shareware that could help out.

                                       CCC

------------------------------

Date:    03 Nov 89 17:44:32 +0000
From:    [e-mail] (Paul Kerchen)
Subject: Re: Checksum programs

In article <[e-mail]> [e-mail] (Leona
rd P Levine) writes:

>The checksum program and the checksum should be stored in a place that is
>different on each machine.  Furthermore, there is no special "best"
>crc or testing algorithm, many will do with varying polynomials.

True, but the checksum program must have some way of knowing what
these algorithms are and where the checksums are stored.  If the `sum
program can find these things, so can a virus.  If the `sum program
must be told where these things are then there is no problem; the
virus cannot find the info it needs because it isn't on the system.
However, that could become tedious for administrators who oversee
tens or hundreds of machines, detracting them from their real work.

>A satisfactory system is one in which each user can use a polynomial
>of his/her choice and where the list of files and their crc's
>(for example) is stored in some arbitrary location.  No virus writer
>will be looking for YOU, rather just a collection of systems that
>are alike enough to infect.

Again, where are these polynomials stored?  One must keep this fact
in mind: a virus can do anything a legitimate program can do.  A "good"
virus will be able to adapt to minor changes in systems and find out
where these things are hidden.

I don't mean to play the devil's advocate here, but I think it's
important to realize that no solution will be a 100% solution.  There
are a lot of people who read this newsgroup, some of whom may not
realize this point, and it always pains me to hear about someone who
invested all of their trust into some vaccine, only to get burned by
the next virus to come down the pike; they didn't realize the
complexity of the problem and jumped right on to someone's bandwagon.
Folks have to realize that all of the vaccines, filters, shields,
latest & greatest methods, etc.,  will only slow viruses down; they
won't stop them.  Of course, if the resposible computing community can
make it so difficult for the degenerate virus writers to make a
living, perhaps those degenerates will find something else to occupy
their time, like making crank calls or torturing small woodland
animals.

Paul Kerchen                            | [e-mail]

------------------------------

Date:    Fri, 03 Nov 89 13:10:39 -0500
From:    [e-mail]
Subject: WANK Antidote (VAX/VMS/DECnet)


              *********** WANK WORM VACCINE  **************

A vaccine to combat the WANK worm has been developed by Bernard Perrot
of the Institut de Physique Nucleaire, Orsay, France.

The vaccine consists of creating a bogus file which you put in
SYS$SYSTEM:RIGHTSLIST.DAT.  When the worm tries to use the information
in this file, the worm-code generates errors and blows up causing the
attacking worm to die. The vaccine does NOT affect the remote system -
it only kills the worm.

This vaccine will stop attacks from any attacking nodes, it should
therefore greatly reduce the "annoyance level" of attacks by reducing
the volume of audit trails.

  ******************* IMPORTANT IMPORTANT IMPORTANT ***********************
                                PLEASE READ!!!

THIS VACCINE WILL ONLY WORK AGAINST **CURRENT** STRAINS OF THE WORM.
WE BELIEVE HOWEVER THAT TO ELIMINATE THIS WORM FROM THE NETWORK, THIS
TECHNIQUE WILL HAVE TO BE USED ON AS MANY SYSTEMS AS POSSIBLE.  IT IS
THE ONLY WAY TO ATTACK THE WORM AT IT'S SOURCE (short of system
management action on the infected node...and a lot of system managers
are either asleep, ignorant, lazy or??? and therefore the worm has
been running on some systems for days).

******************************************************************************

This method has been tested on VMS 4.7 thru VMS 5.2 systems. In order to
correctly implement this fix, the following steps must be performed:

1)  If you have previously implemented any of our suggestions regarding
    file protection or ACL's on RIGHTSLIST.DAT, it is necessary to undo them
    restoring SYS$SYSTEM:RIGHTSLIST.DAT to its original configuration.

2)  RENAME the file SYS$SYSTEM:RIGHTSLIST.DAT to some other name of
    your choosing.

3)  To make VMS operate correctly with the rightslist file in a new
    location, issue the following command, and also add it to your
    system startup procedure:

       $DEFINE/SYSTEM/EXEC RIGHTSLIST <ddcu:[dir]new-file-name>

    The worm won't find the file because it can't translate the
    logical symbol.

4)  Take the 4-line file listed below, protect it W:R and do not
    put an ACL on it.  Name it SYS$SYSTEM:RIGHTSLIST.DAT.  You *WANT*
    the worm to access this file!  Users on your system will translate the
    system logical RIGHTSLIST and things will work correctly.

When an infected system attacks your node, the first thing it does is
copy your sys$system:rightslist.dat file and tries to get your local
usernames.  This dummy file will cause the attacking worm to abort with
a fatal error when it tries to use the information it finds in the
bogus file.

If you have followed each of the above steps, VMS will run normally, and
you will not be vulnerable to the CURRENT strains of the worm which are
running aroung the network.

The following file should be copied into SYS$SYSTEM:RIGHTSLIST.DAT exactly
as it appears below:

- -------------------------- CUT HERE - RIGHTSLIST.DAT -----------------
DUMMY MAINTENANCE RECORD
0123456789012345"'F$PID(ON)
0123456789012345'F$PID(ON)
0123456789012345BATCH
- --------------------------- CUT HERE ----------------------------------

John McMahon of NASA/GSFC Advanced Data Flow Technology Office has
created a command procedure that will have the same end-result as the
above instructions.  It is available by copying WANK_SHOT.COM from
NSSDCA::WANK_SHOT.COM or 6277::WANK_SHOT.COM.  This command procedure
uses a modification of the above procedure using a SET FILE/ENTER
command to set up an alias for RIGHTSLIST.DAT rather than the RENAME
command above. Knowledgable system managers may want to decide for
themselves which version they prefer.

Todd Butler                                Ron Tencati
SPAN/GSFC Routing Center Manager           SPAN Security Manager
[phone]                              [phone]
6277::Tbutler or NSSDCA::tbutler           6277::Tencati or NSSDCA::Tencati

------------------------------

Date:    Fri, 03 Nov 89 13:38:54 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Virus Invasion of Hardware?

Is it possible to write a virus that will invade hardware?  Has it
been done?  Just curious.

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Fri, 03 Nov 89 13:50:53 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Macintosh Virus List (Mac)

Recently I have been writing an article on Macintosh infections.  In
writing the article I tried to compile an exhaustive list of Macintosh
viruses. Below is the list.  If anyone has anything to add to the list
I would appreciate them notifying me so I can update the list.  Thanks
much!

=================================  CUT HERE  ==================================

Macintosh Infections
- ----------------------
There are about eight Macintosh infections that are known at present
(a list of infections and the years in which they first appeared
can be seen in the following table).

- ------------------------------------------------------------

Infection                  Strains           Clones
- ----------                 -------           ------
Scores(Spring 1988)*
nVir(Early 1988)
                           nVir A(?)
                           nVir B(?)
                                             Hpat(Late 1988)
                                             AIDS(Late 1988)
                                             MEV#(March 1989))
                                             nFLU(August 1989)
INIT 29(Late 1988)
ANTI(Early 1989)
MacMag(December 1987)**
Dukakis(Early 1988?)
SNEAK(?)
San Jose Flu(?)

- ------------------------------------------------------------

*  - also known as the NASA virus
** - also known as the Drew Virus, Brandow Virus, and the Peace
      Virus

==================================  AND HERE  =================================

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Fri, 03 Nov 89 14:41:00 -0500
From:    [e-mail]
Subject: Identify Ashar Virus

We encountered a boot sector virus yesterday that we have not seen,
can anyone help with identification and explanation?  The virus has
only been identified on disks that also contain the Pakistani Brain
Virus.  Further, we have only seen it on three diskettes, thus far.

When we run Viruscan 0.7V42 on an infected disk, here is what we see:

" Found Pakistani Brain Virus in boot sector.
  Found Ashar Virus in boot sector.

Disk B: contains 1 directories and 5 files.
 ld viruses found.  "

Please also observe that the number of viruses found is oddly noted.
I have only noticed that phenomenon when the Ashar virus has been
identified.

Light shed by anyone concerning this virus would be greatly appreciated.

Tom Sheriff
Microcompuer Support Manager
UNC Greensboro - Greensboro, NC
[e-mail]
[e-mail]

------------------------------

Date:    01 Nov 89 15:16:07 -0500
From:    "David Chess" <[e-mail]>
Subject: re: VGA2CGA infected with virus? (PC)

I have a sample of this thing (or what I assume is the same thing) now;
it seems to be a rather silly overwriting-virus (that is, rather than
arranging to execute more or less silently before the victim, it
simply arranges to execute *instead of* the victim; the victim code,
at least much of it, no longer exists).   It also seems to be written
in a Borland language, perhaps Turbo Pascal.   It's very possible that
it's based on the Turbo Pascal overwriting-virus "Number One", source
for which was published in the Burger book "Computer Viruses, a
high-tech disease".   I haven't taken it apart enough to know,
for instance, what damage if any it does, or when it prints its
message; it's hard to reverse-compile compiler output, and this
virus isn't likely to spread very far (since an infected file
is obviously infected, in that it doesn't do what it used to...).

DC

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday,  6 Nov 1989    Volume 2 : Issue 232

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Missing 200K Trojan Horse? (PC)
The Brain Virus (PC)
Virus List - Notes (Mac)
Digital signatures for virus protection
Re: Greg Gilbert's virus list (Mac)
Re: Identify Ashar Virus
Re: Identify Ashar Virus
Morris to be tried

---------------------------------------------------------------------------

Date:    Fri, 03 Nov 89 14:03:35 -0500
From:    Peter Jaspers-Fayer <[e-mail]>
Subject: Missing 200K Trojan Horse? (PC)

   I know this is probably not a virus (SCANV45 does not see anything),
but it DID seem to migrate from one PC to another.  What happened was
that someone called me saying that they were missing about 200K of RAM,
even after disabling CONFIG.SYS & AUTOEXEC.BAT.  He reported that
re-SYS-ing the HD fixed the problem, and we closed it... But then someone
(who had been trading CD-ROM software with the 1st guy) complained about
exactly the same symptoms.  I managed to grab a copy of the DOS startup
files, and found only ONE difference between the IBMDOS.COM on their HD
and the one on the original DOS 3.1 diskette.  3 bytes were changed.
DEBUG output follows:

- -N IBMDOS.HD  * This is the hidden file Ibmdos.com on the hard disk.
- -L
- -D 6AC0
303F:6AC0  03 8B 37 43 43 26 88 56-00 26 88 76 01 53 51 52   ..7CC&.V.&.v.SQR
303F:6AD0  E8 41 B0 26 B8 00 20 36-3B 06 36 00 76 04 36 A3   .A.&.. 6;.6.v.6.
303F:6AE0  36 00 5A 59 5B 8C D8 5E-1F 26 89 76 12 26 8C 5E   6.ZY[..^.&.v.&.^
303F:6AF0  14 1E 56 FE C6 FE C2 8E-D8 83 C5 20 E2 C3 5E 1F   ..V........ ..^.
- -U 6AD0
303F:6AD0 E841B0        CALL 1B14
303F:6AD3 26            ES:
303F:6AD4 B80020        MOV  AX,2000            <----------- Huh?
303F:6AD7 36            SS:
303F:6AD8 3B063600      CMP  AX,[0036]
303F:6ADC 7604          JBE  6AE2
- -Q
- -N IBMDOS.FPY * This is the hidden file Ibmdos.com on the original floppy
- -L
- -D 6AC0
303F:6AC0  03 8B 37 43 43 26 88 56-00 26 88 76 01 53 51 52   ..7CC&.V.&.v.SQR
303F:6AD0  E8 41 B0 26 8B 46 02 36-3B 06 36 00 76 04 36 A3   .A.&.F.6;.6.v.6.
303F:6AE0  36 00 5A 59 5B 8C D8 5E-1F 26 89 76 12 26 8C 5E   6.ZY[..^.&.v.&.^
303F:6AF0  14 1E 56 FE C6 FE C2 8E-D8 83 C5 20 E2 C3 5E 1F   ..V........ ..^.
- -U 6AD0
303F:6AD0 E841B0        CALL 1B14
303F:6AD3 26            ES:
303F:6AD4 8B4602        MOV  AX,[BP+02]         <----------- Huh ?
303F:6AD7 36            SS:
303F:6AD8 3B063600      CMP  AX,[0036]
303F:6ADC 7604          JBE  6AE2
- -Q
- -------------------------------------------------------------------------

   I do not have any idea how the file got changed.  The date-stamps were
changed (in both cases).  The attribute flags (Sys, R/O, Hidden, Arch all
set) were not changed.  SOMETHING re-wrote 3 bytes of IBMDOS.COM, even
though it was R/O, and the write was such that the date-stamp was changed
to the current date.  As far as we can tell, the missing 200K was the only
symptom.  The CD-ROM stuff they were working on was using the
Microsoft-Extensions software, plus the usual .SYS files for CDs.

Does anyone have any ideas what happened here?

 /PJ
                     -------------------------------
Notices you don't want to find printed on the back of your computer:
"NO USER SERVICEABLE PARTS INSIDE",  "SOME ASSEMBLY MAY BE REQUIRED",
and everyone's favorite "BATTERIES NOT INCLUDED".

------------------------------

Date:    Fri, 03 Nov 89 14:52:43 -0600
From:    [e-mail]
Subject: The Brain Virus (PC)

Can anyone refresh me on the damage that the "Brain" virus can do to a
diskette.  I have infected diskettes as identified by IBM's VIRSCAN.
Any information is appreciated.  [e-mail]

------------------------------

Date:    Fri, 03 Nov 89 16:16:33 -0500
From:    Joe McMahon <[e-mail]>
Subject: Virus List - Notes (Mac)

I believe that the Peace virus appeared first - at least it was the first
discussed, with nVIR and Scores following, in that order. I keep repeating
this, but no one ever seems to see it:

         ----  There is no such thing as a SNEAK virus !!!  ----

This was simply a convenient name for a particular virus-like code
pattern that Bob Woodhead's "Interferon" program looked for - for
those who are interested, an immediate branch out of CODE 0 to some
other CODE segment.  There is no specific virus called SNEAK, and
there never has been. Bob has mentioned before that he's sorry he used
this unfortunate appelation.  Me, too. Please, tell your friends,
there's no such thing. If you read the Interferon documentation, this
is all explained in it.

As to the San Jose Flu, I've never heard of it, and I don't believe
that it's ever been discussed here. If you have more details, I'd like
to see them.

Everything else looks OK. Thanks for taking the time, Greg.

 --- Joe M.

------------------------------

Date:    Fri, 03 Nov 89 16:58:48 -0800
From:    well![e-mail] (RSA Data Security)
Subject: Digital signatures for virus protection

The most effective method available to detect *any* change to a
program is through the use of digital signatures.  A "message digest"
(much more mathematically secure than a checksum) is encrypted with
the private key of a public key cryptosystem (the private key may be
yours or someone you trust).  The verification process is then as
follows:

- -     recompute the message  digest
- -     decrypt the encrypted message digest with the public key
        of the "signer" - the public key need not be secret
- -     compare the two

If they match, the file is unaltered.  No one can recompute and
attach a mailicious signature since only the signer holds the private
key.  One paper by Maria Pozzo & Terry Gray of UCLA in January 1987
describes in detail how an operating system can use digital
signatures based on public key cryptosystems to execute only
"trusted" programs.

Since no one can "forge" a signature, it is possible that
software developers can "sign" their programs, essentially taking
responsibility for their contents.  This would provide a strong
incentive for the publisher to ensure a program was clean before
signing it.  Note: there are simple, effective ways to validate
public keys before using them to verify signatures.

There are inexpensive commercial products available now for DOS, Mac
OS, UNIX and VMS that do exactly this.  They use a *secure* message
digest algorithm which is 60 times faster than DES on 32 bit
machines.  The digest size is 128 bits (anything less is *not*
cryptographically secure - there are a number of papers on the
subject).

Simple uses of DES has even been shown to be unsafe for checksums; it
is vulnerable to attacks based on the birthday paradox which says
that as the number of *useful* message variants approaches the square
root of the total number of possible checksums (2^64 with DES), the
probability that an attacker can match a checksum with a useful
modified message exceeds 50%.  Since (at least in DOS) you can add
any number of bits to the end of a program without affecting its
execution, programs are particularly vulnerable.

Disclaimer: RSA Data Security designs, develops and markets the
above mentioned software.

Jim Bidzos

------------------------------

Date:    Sat, 04 Nov 89 09:17:38 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Greg Gilbert's virus list (Mac)

In Virus-L V2 #231, "Gregory E. Gilbert" <[e-mail]>
writes about a list of Mac Viruses.  Greg's list contains several noteworthy
errors.

1 -- SNEAK is not a virus.  SNEAK is a term Robert Woodhead uses to denote code
     that is suspicious, but is not part of any known virus.  For example, if
     you run Interferon 3.1 on Tops 2.1, you will get a SNEAK warning because
     of the way Tops is written.

2 -- The "San Jose Flu" was an early name given to Scores.  Scores was first
     detected by Dave Lavery over at NASA Headquarters here in Washington DC.
     Two weeks after being found at NASA (thus the name "NASA Virus"), it was
     found in the San Jose area (hence the name "San Jose Flu").  Both were
     found to be the same virus.

     Scores gets its name from a file it creates in the System Folder entitled
     "Scores"

3 -- While not a mistake per se, Greg should point out that the Dukakis Virus
     is a virus directed at applications built with Hypercard (in Apple
     paradigm:  Hypercard Stacks).  Dukakis presents no threat (in a strict
     interpretation of the term) to other applications.  [In other words,
     Dukakis can only infect Hypercard Stacks, but not applications such as
     Excel, Versaterm, Canvas, and so on.]

David Gursky
Member of the Technical Staff
Special Projects Department, W-143
The MITRE Corporation

------------------------------

Date:    06 Nov 89 03:38:42 +0000
From:    munnari!stcns3.stc.oz.AU![e-mail] (Dave Horsfall)
Subject: Re: Identify Ashar Virus

In article <[e-mail]>,
    [e-mail] writes:

| When we run Viruscan 0.7V42 on an infected disk, here is what we see:
|
| Disk B: contains 1 directories and 5 files.
|  ld viruses found.  "
|
| Please also observe that the number of viruses found is oddly noted.

Obviously the result of a `printf("... %ld viruses found.", ...)'
without the `%'.  Doesn't do much to inspire confidence in the
program's author, does it?

On another note, I'm curious to learn just how generic the virus
problem is.  We've seen the Internet worm, the DECNET worm, the
Christmas Tree virus, many PC/Macintosh/Amiga viruses etc etc.

Anyone seen a CP/M virus yet?  My home system is a CP/M-80 box,
and I need to know whether to worry or not :-)

- --
Dave Horsfall (VK2KFU),  Alcatel STC Australia,  [e-mail]
[e-mail],  ...munnari!stcns3.stc.oz.AU!dave

------------------------------

Date:    06 Nov 89 11:06:05 +0000
From:    [e-mail] (Rob J. Nauta)
Subject: Re: Identify Ashar Virus

In article <[e-mail]> [e-mail]
 writes:
>When we run Viruscan 0.7V42 on an infected disk, here is what we see:
>
>" Found Pakistani Brain Virus in boot sector.
>  Found Ashar Virus in boot sector.
>
>Disk B: contains 1 directories and 5 files.
> ld viruses found.  "
>
>Please also observe that the number of viruses found is oddly noted.

That's something I noticed too. On a disk with the pingpong virus, viruscan
0.7V42 says (and some earlier versions did too)
  Found pingpong virus in bootsector
  Found pingpong virus-Version B in bootsector

Disk A: contains 1 directories and xx files.
  ld viruses found.
The ld viruses found is an interesting bug... Also bootsector viruses seem ti
be reported twice.

Greetings
Rob

------------------------------

Date:    Mon, 06 Nov 89 07:03:15 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Morris to be tried


>From the Washington Post -- 5 November 1989:

U.S. Judge Rules Computer `Worm' Case to Be Tried  (Associated Press)

   SYRACUSE, N.Y. -- A federal judge ruled Friday that the case of
a former graduate student accused of unleasing a "worm" program into
thousands of computers nationwide can go to trial.

   U.S. District Judge Howard Munson rejected pleas from the lawyer
for Robert T. Morris Jr. to dismiss a felony computer-fraud charge
on the grounds that information leaked by the Justice Department
would prevent him from receiving a fair trial.  Munson set the trial
to begin Nov. 29.

   Morris's lawyer, Thomas Guidoboni, contended the Justice Department
improperly revealed to a reporter before Morris was indicted in
July that Morris had given a statement to prosecutors and that the
department was considering whether he should be allowed to plead
guilty to a misdemeanor.

   In November 1988, a "worm" program that prosecutors said Morris
created clogged a network of about 6,000 computer shared by colleges,
research centers and the military.  It took several days to cleanse
the network of the program, which multiplies out of control.

   Morris, 24, of Arnold, Md., became the first person in the country
to be charged criminally under the 1986 Computer Fraud and Abuse Act
when he was indicted on a charge of gaining unauthorized access to
computers and causing losses in excess of $1,000.  He faces up to
five years in prison and a $250,000 fine if convicted.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday,  6 Nov 1989    Volume 2 : Issue 233

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Virus source available in Toronto
Re: Where are the Sophisticated Viruses?
virus protection strategy questions
New anti-virus programs uploaded to SIMTEL20 (PC)
More CRC suggestions
Re: Brain and Ashar virus (PC)
Re: Brain Virus Query (PC)
KillVirus (Mac)
CRC Checking.
Typo vs. Typo (PC)
NP completeness

---------------------------------------------------------------------------

Date:    06 Nov 89 11:48:16 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Virus source available in Toronto

[e-mail] (Kelly Goen) writes:

>the published sources working or non working are really not
>that much of a threat...

Wrong !

One concrete example why: The "Ghost" virus recently found here in
Iceland seems to have been based on the listing of the Vienna virus
from the book "Computer Viruses: A High Tech Disease" This is clear
becuse the virus contains the two patches added there to make the
virus a little less harmful than the original Vienna virus.

Since any assembly language programmer should be able to create a new
working virus in a day given a listing or a good (commented)
disassembly, this gives us a good reason to limit the availability of
virus listings as much as possible.

- -frisk

         Fridrik Skulason          University of Iceland
         [e-mail]           Computing Sevices
         Guvf yvar vagragvbanyyl yrsg oynax .................

------------------------------

Date:    Sun, 05 Nov 89 23:04:41 -0700
From:    ctycal![e-mail]
Subject: Re: Where are the Sophisticated Viruses?

There are probably two reasons why the viruses you suggest do not
exist:
  1) If the system code is bypassed, then it must be rewritten.
     Most hackers are not at that level.  Those that are that
     proficient are busy making money.
  2) Code to do all the stuff needed would be quite large, and
     therefore noticeable.  If you add 20 K to somebody's
     programs they will likely notice.

Anyway, viruses experience exponential growth.  At the beginning
the spread is very slow and only becomes rapid after a fair while
(say 6 months).  This allows the wary to catch most viruses.

  Terry Ingoldsby                       ctycal![e-mail]
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb

------------------------------

Date:    06 Nov 89 16:14:57 +0000
From:    [e-mail] (steven l. odegard)
Subject: virus protection strategy questions

     For personal computers, I can imagine Mom giving me advice to keep me
from catching cold, [a biological virus]:

     1.  Wear your coat.  Keep yourself warm.  Don't expose yourself.
The 3 1/2 inch disks have a little write-protect tab.  If the disk is
set to safe (where you may see through the hole), no data may be
written to it, including virus's data.  5 1/4 or 8 inchers have a side
slot which must be covered with black vinal tape to write-protected
them.  Is it reasonable to install write-protect toggle switches for
hard disks on a personal computers?  I use the write-protect all the
time on larger computers -- once a machine (software) crashed and
destroyied the work of one-hundred people the previous week!

     2.  Stay out of garbage.  Use only reliable 'clean' software
purchased from reputible software dealers.  How often is
food-poisioning contracted from eating food from clean restaurants?
There are a few cases software published with unknown viruses lurking
in them, but such are usually detected quite rapidly.

     3.  Quarantine:  I have no experience here, is it practical to switch
infected systems off of local-area networks?  (unplug them)?

    What other common-sense strategies (as opposed to unreasonable
panic strategies) are there to prevent these infections?  Should
terminate and stay resident programs be purged and reloaded from time
to time, for example?

    I am reminded of a similar phenomena occurring on larger computer
systems, where the terminals they employ have a code for "transmit
25th line".  Then simply typing some file can cause you to lose all
your files: the file contains the code to put "ERASE *.*" on the 25
line, and transmit.  The computer sees the data stream "ERASE *.*" and
proceeds to erase all files on the account.  The cycle can be broken
by disallowing the 25line code from appearing in the output -- use
special 'display' program, or disabling the transmit 25th line command
- -- install a toggle switch on the terminal, or by being careful what
you look at -- be aware of the problem.

- --SLO [e-mail] uw-beaver!wwu.edu!8243274 [e-mail]

------------------------------

Date:    Sun, 05 Nov 89 19:37:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: New anti-virus programs uploaded to SIMTEL20 (PC)

I have uploaded the following files to SIMTEL20:

pd:<msdos.arc-lbr>
SHEZ49.ARC      Shell for archive manipulation, w/virus check

pd:<msdos.trojan-pro>
CKOT094.ARC     Checks archived files for viruses (req. SCANV)
NETSCAN.ARC     Network compatible - scan for 46 viruses, v46
SCANRS47.ARC    Resident program to scan for many viruses
SCANV47.ARC     VirusScan, scans disk files for 47 viruses
VALIDAT3.ARC    Validate shareware programs for authenticity

CKOT094, NETSCAN, SCANRS47 and SCANV47 were obtained directly from the
Homebase BBS.

- --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    Sat, 04 Nov 00 19:89:58 +0000
From:    agora.hf.intel.com![e-mail]
Subject: More CRC suggestions

[e-mail] (Leonard P Levine) writes:

> A satisfactory system is one in which each user can use a polynomial
> of his/her choice and where the list of files and their crc's
> (for example) is stored in some arbitrary location.  No virus writer
> will be looking for YOU, rather just a collection of systems that
> are alike enough to infect.

The CRC program should encrypt and authenticate its stored data file(s);
otherwise, it'd be easy for a savvy virus to essentially 'grep' for strings
matching the format of those used by common CRC programs, and then modify
that file.

Even niftier would be 'roll-your-own' CRC programs, that encourage the user
to modify and recompile them from available source; that way, virus authors
couldn't compensate for just a few very popular CRC checkers, and would
have to contend with thousands (probably millions) of different versions
with different filenames and methods of storing the CRCs.

[However, the above immediately brings to mind hacked versions of the
source, intended to trick nontechnical users into compiling and running
evil programs.  I suppose we could get the source code from a few
(authentic) sources, along with CRCs for that source code... :)  Sigh.]

Another thought:  for people with access to EPROM burners, howzabout
burning the (encrypted) CRCs into EPROMs?  (I'm thinking primarily of PC
clones, with their relatively easily accessible ROM sockets)  Whenever new
software is installed, the old EPROM could be wiped and reprogrammed.

- --
".. organized crime is the price we pay for organization." - Raymond Chandler

Greg Broiles          | CI$:      74017,3623   |      [e-mail]
3105 Pine St.         | WWIVnet:  1@5312       |
Riverside, CA  92501  | Peacenet: gbroiles     |   tektronix!tessi!agora!greg

------------------------------

Date:    Sun, 05 Nov 89 15:34:17 -0500
From:    [e-mail]
Subject: Re: Brain and Ashar virus (PC)

I had the same experience as you did Tom, when using SCANV42 to scan a
diskette I knew was infected by the Brain virus.  I contacted John
McAfee, the author of the program, and was told that that was a bug in
that particular version of the program.  Evidently, he choose
overlapping hex strings as his virus signatures, so even though only
the Brain virus was actually present, a false positive reading was
obtained for the Ashar virus.  I haven't tested it yet, but I'm sure
that this bug has been corrected in the latest versions of the program
(what are we up to now, version 48 or so?).  Hope this clears things
up.

------------------------------

Date:    Mon, 06 Nov 89 09:31:23 -0500
From:    [e-mail]
Subject: Re: Brain Virus Query (PC)

In response to your query about the Brain virus, I have included
some information below that was put out by the Computer Virus
Industry Assoc.  The only things I would add to that description
are that the virus does not infect hard disks, only floppies.  The
virus is non-destructive in that it is not specifically designed
to damage any files (except the boot sector)--the damage comes in
when it writes over the seven sectors, in a random location in the
data area of the diskette, which may be part of a program or data
file.  The program may then not run or the data may be corrupted,
but this is just a side-effect, so to speak.  The virus is
prevalent at locations which have public-access floppy-based
systems such as universities.

An infected disk (but not the files) can be recovered by
formatting.  The sectors flagged as bad can even be recovered if
you have a utility such as Norton's that can directly modify the
File Allocation Table, and you use it before you reformat the disk.
If you perform the DOS SYS command, it will render the virus
inactive by rewriting the boot sector and your files will still be
there, although the bad sectors will also still be present and
whatever damage was done will not be repaired.

Hope this information helps!

- -----------------------------------------------------------------

Name:  Pakistani Brain

Origin:  Lahore, Pakistan, January 1986; developed
           by two brothers as an experiment
Host:  IBM PCs and compatibles
Class:  Boot sector infector

Description:
- - Replaces original boot sector with itself
- - Moves original boot sector to another location
- - Adds seven sectors that contain remainder of virus
- - Flags all modified sectors as unusable to protect itself
- - Replicates onto all inserted bootable floppies

How spread:
- - Booting from unknown or shared disks
- - Infects through any access to an inserted disk
    Listing directories, executing programs and so on
    Through software reboot sequence

Symptoms:
- - Copyright @BRAIN label displayed in directory of infected disk
- - Reboot sequence slowed down
- - Excessive floppy activity for simple tasks
- - Program crashes for some versions of DOS
- - Interrupt vectors modified

Potential damage:
- - System crash can cause loss of data
- - Spreads quickly to all bootable disks

Precautions:
- - Do not boot from unknown floppies
- - Boot only from the hard disk if one exists
- - Write-protect all boot disks

Recovery:
- - Shut down infected systems
- - Reboot from a clean, write-protected original boot disk
- - List directory of all disks - look for @BRAIN label
- - When found, destroy the disk, or:
    Perform DOS SYS command to rewrite boot sector
    Recreate volume serial label using any available utility
    (This procedure will still leave 7 bad sectors with dead virus)

Notes:  Will live through software reboot.

------------------------------

Date:    Mon, 06 Nov 89 12:27:20 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: KillVirus (Mac)

Does KillVirus have an nVir "resource".  ("nVir" visible when examined
with ResEdit.)  Or do I have problems with my copy of KillVirus.
Thanks much.

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Mon, 06 Nov 89 10:34:26 +0000
From:    Martin Ward <[e-mail]>
Subject: CRC Checking.

How about this for a system:

Keep the CRC checker program and file of checksums on a separate
bootable floppy, which has a suitable AUTOEXEC.BAT file. At the end of
the day, power down, insert this floppy and power up. The machine
boots off this floppy and is therefore guaranteed free from active
viruses, it then automatically checks all executables on the hard disk
for any changes. The same disk could go on to do a backup
automatically once the machine has been declared free of infections.

        Martin.

My ARPANET address is:  [e-mail]
OR: [e-mail]  UUCP:...!mcvax!ukc!easby!martin
JANET: [e-mail]    BITNET: [e-mail]

------------------------------

Date:    Mon, 06 Nov 89 19:12:45 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Typo vs. Typo (PC)

There have been two viruses reported in the PC world, with the name "Typo".

    One is a boot sector virus - a modification of the Ping-Pong
    virus. This virus was written in Israel.

    The other virus is a resident .COM infector, 867 bytes long.
    This one is of U.S. origin.

Since having two viruses with the same name will only lead to confusion,
something needs to be done. Any suggestions ?

- -frisk

------------------------------

Date:    06 Nov 89 20:27:02 +0000
From:    [e-mail] (Paul Kerchen)
Subject: NP completeness

Recently, I posted an article in which I stated that the virus problem
was NP complete.  Well, a number of people pointed out my error and so
I'd like to apologize.  What I meant to say was that the virus problem
(at least detection, anyway) is undecideable.  However, despite this
problem, I still contend that no virus solution will be a 100%
solution.  I'd like to thank the people who politely pointed out my
mistake and the folks who were less than gracious can...well, you know
what you can do.  I'll have to watch my NP's and Q's more closely
(sorry, I couldn't resist).

Paul Kerchen                            | [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday,  7 Nov 1989    Volume 2 : Issue 234

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Datacrime report at ERIM followup (PC)
Re: Where are the Sophisticated Viruses?
Re: Imbeded virus detection
Re: 2608- possible virus? (AMIGA)
Re: Macintosh Virus List (Mac)
dBase and Typo-COM viruses (PC)
Re: CRC's
SCANV42 and ASHAR Virus (Mac)

---------------------------------------------------------------------------

Date:    Mon, 06 Nov 89 13:46:07 -0500
From:    Arthur Gutowski <[e-mail]>
Subject: Datacrime report at ERIM followup (PC)

A couple of weeks back, I posted an article concerning a Datacrime hit
at the Environmental Research Institute of Michigan (ERIM).  More
recent info precludes any correlation of the hit with the discovery of
the name Siegmar Schmidt in the partition table.  I recieved a message
from Leo Stephens (also a subscriber to Virus-L), in which he said
that a friend of his had also discovered this name in the partition
table.  He also had found the name David Litton on some of his
machines at work, and others had no name at all.  A couple of people
who know more about partition tables and editors than I do suggested
that it was just the author of the editor taking credit for the
program by placing his name there (there is enough unused space in the
partition sector to do this harmlessly).  All of the other occurences
of names have come without any disk problems associated with a virus
(McAfee's Scanv46 and IBM's Virscan was used on on the above disks).
I guess the moral of the story is to just make sure pertinent data
does not change.  But, if anyone else can confirm that these names
aren't anything too out of the ordinary, it would set my mind (and
computer) at ease.

Again, my friend at ERIM did get hit by a Datacrime version either by
an bum copy of PKZ102.EXE or his FDISK program became
infected...Siegmar is innocent.

+--------------------------------------------------------------------+
| Arthur J. Gutowski                                                 |
| Antiviral Group / Tech Support / WSU University Computing Center   |
| 5925 Woodward; Detroit MI  48202; PH#: [phone]              |
| Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]       |
+====================================================================+
| "To do is to be."  -Socrates  "To be is to do."  -Plato            |
| "Do-bee do-bee do."  -Sinatra  "Yabba dabba doo."  -Fred Flintstone|
+--------------------------------------------------------------------+

------------------------------

Date:    Mon, 06 Nov 89 20:54:24 +0000
From:    [e-mail] (jim frost)
Subject: Re: Where are the Sophisticated Viruses?

[e-mail] (David.M..Chess) writes:
>You're forgetting one important kind of virus detector: a
>general modification-detector that does a check-code of some
>kind (CRC, MDC, or whatever), and alerts the user when
>a file's *contents* (not the date) change.
>I think even
>a virus that talked straight to the hardware to avoid
>"suspicious activity" detectors wouldn't get far before
>it was detected.                        DC

Sigh.  We're lucky that no very competent programmer has tried to
write a virus, all right.  Consider that there are three phases to any
virus, not including side-effects such as damaging data:

        1) infection
        2) propagation
        3) survival

A sophisticated virus spends almost all of its time surviving, so it's
the most interesting stage.  Survival traits include:

        * limiting propagation rates
        * limiting re-infections
        * detecting and avoiding "virus-protected" hosts
        * staying within normal system activity boundaries
        * hiding from standard system utilities
        * modifying hosts to make them more susceptible to
          re-infection

There are a lot more things that a sophisticated virus can do, but
these are food for thought.  Let's examine them in more detail.

Limiting Propagation Rates.  Simple viruses, and often not-so-simple
ones, will proliferate without bounds.  Rampant proliferation will
cause the virus to be noticed early in its lifetime and will probably
lead to its early demise.  The internet worm did not do this.

Limiting Re-Infections.  Most simple viruses don't detect systems
which have already been infected and will re-infect them.  Such
viruses will incrementally eat system resources until they are
noticed.  The internet worm did not do this.

Detecting and Avoiding "Virus-Protected" Hosts.  I have yet to see a
virus which looked at the state of a system to detect virus detection
mechanisms to nullify them and/or avoid infecting them.  There are a
variety of simple ways which a virus could do this, especially on
PC-based systems where hardware and software is extremely standard.  A
virus which did this might go undetected forever.  Of course it's
possible that such a beastie exists and is undetected.  Even CRC
detectors will not detect a properly written virus which avoids
systems with CRC detection mechanisms!

Staying Within Normal System Activity Boundaries.  Some viruses will
actively search devices which a user did not request activity from;
this activity will often be noticed.  A good many Apple II viruses had
this trait, and so did the internet worm.  It leads to early
detection.

Hiding From Standard System Utilities.  A sophisticated virus would
avoid showing anomalies when the system is perused with standard
system utilities such as those which display currently active
processes, memory or disk usage, etc.  Given the primitive state of
many PC operating systems, this capability is seldom needed, and it's
easy to remain unnoticed on larger systems without any effort at all.
The internet worm had some of these avoidance techniques which made it
much harder to track down.

Modifying Hosts To Make Them More Susceptible To Re-Infection.  A very
sophisticated virus could make subtle changes to an operating system
or operating system environment to make it easier to re-infect.  This
capability is generally useless amongst PCs but it's extremely easy to
make small modifications to many multiuser systems -- particularly
UNIX -- to make re-infection trivial.  I believe a recent VMS virus
did this by adding a user, although I'm not certain of that.

[Ed. The DECnet WANK worm did indeed add (or alter an existing)
username, FIELD.  It also modified .COM files (which are shell scripts
on VMS, similar to MS-DOS .BAT files) to do the same if run from a
privileged account.  Making any such changes to MS-DOS PCs would seem
redundant, IMHO.]

By now you should get the idea that almost every virus we've seen is
primitive, although several showed some of the survival traits which I
outline above.  Given the limited resources of PC environments, it's
unlikely that you'll get a very sophisticated virus.  The internet worm
was itself only sophisticated at infection; propagation and survival
techniques were woefully inadequate, although they need not have been
because the infected hosts could have supported a much more
sophisticated virus.

This is food for thought, but should give you an idea of just how
tough a virus could actually be.  Count our blessings now because you
won't believe how bad tomorrow's nightmares will be unless we start
teaching ethics to tomorrow's programmers!

jim frost
[e-mail]

------------------------------

Date:    Sat, 03 Nov 89 14:47:35 +0000
From:    [e-mail]
Subject: Re: Imbeded virus detection

[e-mail] (Bob McCabe) writes:
>   As a consultant who writes software for the PC I am worried
> about the possibility of my programs getting infected and
> becoming vectors by which viri are spread.
>   In particular I am developing an application that will be hand
> carried from site to site to gather data by a number of users. If
> this program were to get infected it could cause wide spread loss
> of data to an important research project, not to mention other
> programs and data on affected systems. I am looking at including
> a check to see if there has been any change in the EXE files.
> Failure on such a check would cause the program to disable it's
> self and report a possible infection.

Easy enough to do: just have something like this (in C):

main (argc,argv)
{
        if (crc_check (argv[0])!=ORIGINAL_CRC_VALUE)
        {
                printf ("Virus infection - now committing suicide!\n");
                unlink (argv[0]);
                exit (20);
        }
        ...
}

ok so you probably wouldn't want the program to actually commit
suicide but it looks good. Only problem is entering the original CRC
value as a constant because putting in the value into the program
would change the executable file and thereby the value ... maybe have
some unused static data you change the value of to compensate and make
the total CRC unchanged.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
[e-mail]

------------------------------

Date:    Mon, 06 Nov 89 12:05:32 +0000
From:    [e-mail]
Subject: Re: 2608- possible virus? (AMIGA)

[e-mail] (Iain Davidson) writes:
> Well, while up in Vancouver, BC at an Amiga Users Group meeting, a
> interesting thing was demostrated.....
>
> I call it the "2608" virus. (don't know the offical name).
>
> It worked like the IRQ virus attaching itself to the first executable in
>   the startup-sequence.  But with a slight twist.  It would copy the
>   found executable to devs:"    " and copy itself into the old name in
>   the "C" directory (size 2608 bytes).

Sounds like BGS-9. Make sure you don't leave any copies on any working
disks because the version of BGS-9 I found trashes sectors of your
floppies.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
[e-mail]

------------------------------

Date:    Sun, 06 Nov 89 04:28:04 +0000
From:    <polari![e-mail]>,
         [e-mail] (robert)
Subject: Re: Macintosh Virus List (Mac)

 > Recently I have been writing an article on Macintosh infections.  In
 > writing the article I tried to compile an exhaustive list of Macintosh
 > viruses. Below is the list.  If anyone has anything to add to the list
 > I would appreciate them notifying me so I can update the list.  Thanks
 > much!

 Your list includes "SNEAK" and "San Jose Flu". I've never heard of the
 "San Jose Flu". Could you furnish more information about this one?

 The "SNEAK" is not a Macintosh virus. This is apparently a generic term
 (like "Trojan Horse" or "Time Bomb") for a type of virus. All uses of
 the term "SNEAK" that I have seen trace back to Robert Woodhead, the
 author of the Macintosh anti-virus program Interferon, and I suspect
 that Robert coined the term himself. The documentation for Interferon
 defines a "SNEAK" as follows:

 003    A SNEAK virus.  This is a virus that adds it's code to a
        common System folder file and changes it's type to INIT so
        that it is run at boot time.  Type 003 is a generic "Virus
        sniffer" that detects if common System folder files have
        been adulterated in this way.  If you get a type 003 virus,
        please get in contact, you may have discovered a new strain.

Interferon was one of the first Mac anti-virus programs and was, at the
time, an excellent (and free) virus detection program (though it should
NOT be used for virus removal!). The intent of the author was, apparently,
to provide checks for possible future viruses. Unfortunately, some software
that was released after Interferon tended to trigger this generic virus
check. The result was that Interferon would report a "SNEAK virus" in cases
where no virus actually existed. Early versions of Interferon found "SNEAK
virus" in the LaserWriter and LaserPrep files that were part of later system
software releases from Apple. Even Interferon 3.1, which is the latest
version of Interferon I have seen (dated May 16, 1988), reported the "SNEAK
virus" in TOPS version 2.1.

These early attempts by Interferon to detect unknown viruses with generic
checks bring out the dangers of such an approach. I get the impression
that the author of Disinfectant, John Norstad, has taken a more conservative
approach and checks only for KNOWN virus entities (resources and files).
I imagine that Robert Woodhead has taken a similar approach with Virex,
his newer commercial anti-virus program (replacing Interferon), though I
haven't had an opportunity to see Virex.

 ---------------------------------------
    Robert Riebman
    robert@polari
    Northwest Information Technology
    P.O. Box 3156
    Redmond, WA   98073
 ========================================

------------------------------

Date:    06 Nov 89 20:45:07 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: dBase and Typo-COM viruses (PC)

Alan J Roberts writes:
>
>        A number of folks have looked at the DBASE virus (Ross
>Greenberg's discovery), including Joe Hirst, Steffan Campbell and T.B.
>Allen, and the general consensus is that the virus is very similar in
>style to the TYPO virus (The COM version).  If the author of these two
>viruses is one and the same person, then perhaps the DBASE author has
>not completely been "re-habilitated" as Ross Greenberg has suggested.

I must disagree. The dBase and Typo-COM viruses are similar in some ways,
but there are also quite a few differences.

Similarities:

1) Both viruses use an identical, but very unusual, method to transfer control
   back to the original program:

                MOV        AX,100
                JMP        AX

2) Both viruses infect files with names ending in .COM, instead of checking
   the first two bytes to determine the type of the file. They will not
   infect .EXE files.

3) The viruses use similar methods to determine if the system is alredy
   infected - defining new interrupt subfunctions.

                dBase:                               Typo-COM:

                MOV        AX,FB0A                   XOR        AL,AL
                INT        21                        MOV        AH,DD
                CMP        AX,0AFB                   INT        16
                JE         infected                  CMP        AL,AH
                                                     JE         not_infected

Differences:

1) Typo-COM will search for programs to infect, looking for *.COM files
   in the current directory. The dBase virus will infect a program when
   it is executed.

2) Typo-COM will install itself in memory when the infected program
   terminates, (by using DOS functions 0 or 4C, or by a INT 20 call).
   dBase will install itself as soon as it has determined that it is not
   already present in memory.

3) The code used to hook INT 21 is very dissimilar, the dBase virus using
   DOS functions, but Typo-COM using direct manipulation.

                dBase:                           Typo-COM:

                MOV AX,3521                      MOV AX,[84]
                INT 21                           :
                :                                MOV [84],SI
                :                                SUB [84],98
                MOV DS,DX                        :
                MOV DX,new_21                    MOV AX,[86]
                MOV AX,2521                      :
                INT 21                           PUSH CS
                                                 POP [86]

4) dBase hooks INT 21 when it is first executed. Typo-COM hooks INT 21,
   INT 20 and INT 16 at the same time, but when it installs itself in memory
   it restores INT 21 and INT 20.

5) The "install in memory" procedure is VERY different. The dBase virus
   manipulates the MCB directly, in a way similar to the method used
   by the Icelandic virus. It will then transfer itself upwards in memory.
   Typo-COM will transfer itself down, overwriting the original infected
   program, as soon as the program exits (see [2] above.)

6) Finally:  The Typo-COM is a "harmless" virus, meaning that it does no
   direct, permanent damage, like destroying data or formatting the hard
   disk. It contains a generation counter, but it does not seem to be used
   (reserved for future expansion ?) All it does is to produce a "typing
   error" every now and then. It is therefore in the "joke" category,
   along with Cascade, Ping-Pong and a few other viruses.

   The dBase virus is quite different. It will garble data when it is written
   and restore it when it is read back. If the system is not infected at the
   time, the data will be useless. This also applies if the virus is removed.
   But, if the file has not been written to for three months when it is
   read, the virus will do serious damage, erasing the first 100H sectors on
   drive D: E: .... Z: - or at least it was designed to do so. The author
   forgot one small detail, which will make the destruction rather
   unpredictable.

   This is a clear difference in attitude, which does not support the
   theory that the viruses have the same author

Comments, anyone ?

- -frisk

         Fridrik Skulason          University of Iceland
         [e-mail]           Computing Sevices

          Guvf yvar vagragvbanyyl yrsg oynax .................

------------------------------

Date:    Mon, 06 Nov 89 22:48:39 +0000
From:    [e-mail] (Charles Kichler)
Subject: Re: CRC's

> A CRC will work if you:
> (1) Keep the polynomial secret and personal.
> (2) Keep   the  comparison  information  secret  and
>     personal.

I don't think this is fool-proof.  The problem is that the polynomial
and the comparison information must be known to the program.  Therefore,
if you know where to look IN THE PROGRAM, then you could find the
information.

I believe the only iron-clad method might be a hardware device which
could verify a programs "health".  I imagine it to be device akin to
those that attach to the serial port of a computer for copy protection.
The advantage is hardware is difficult to modify via software.  As of yet,
I haven't seen a program that can beat a write protect tab.

Charles "chuck" E. Kichler,        Intro. to PC Instructor/Co-ordinator
Computer & Info. Science    Kansas State Univ. * Yesterday,
Internet: [e-mail]           |  I knew the answers.
BITNET: [e-mail]                 * Today,
UUCP: {rutgers,texbell}!harris!kichler         |  they changed the questions.

------------------------------

Date:    Mon, 06 Nov 89 16:33:01 -0800
From:    portal!cup.portal.com![e-mail]
Subject: SCANV42 and ASHAR Virus (Mac)

    Tom Sheriff noted in a recent Virus-L listing that SCANV42
displays an unusual virus number and appears to show both the ASHAR
and the BRAIN virus whenever the BRAIN virus is encountered.  The
duplicate virus messages were caused by new strings added to version
42, fixed in V44.  The "1d viruses found" message has also been fixed
in version 44.  (The "d" was an extraneous character caused by the
duplicate strings).
Alan

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  8 Nov 1989    Volume 2 : Issue 235

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: SCANV42 and ASHAR Virus (Mac...really PC)
Re: Use of the term "SNEAK"
Re: Where are the Sophisticated Viruses?
Macwight Virus (?)
Reviewing a Virus Article
Virus List (MAC)
TROJAN Horse by the name of NORTSTOP (PC)
Previously reported BootChek problems (PC)
Re: Virus source available in Toronto
Re: Where are the Sophisticated Viruses?
need disinfection info for BRAIN virus (PC)
WARNING: Brain virus infection (PC)
Re: Virus List - Notes (Mac)
excerpts from risks-l digest

---------------------------------------------------------------------------

Date:    Tue, 07 Nov 89 07:38:30 -0500
From:    [e-mail] (David Gursky)
Subject: Re: SCANV42 and ASHAR Virus (Mac...really PC)

SCANV42 and the Ashar virus have nothing to do with the Mac :)

[Ed. An embarassed moderator stands corrected.  :-)]

------------------------------

Date:    Tue, 07 Nov 89 07:44:31 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Use of the term "SNEAK"

In Virus-L V2 #234, <polari![e-mail]>,
[e-mail] (robert)
[Robert Riebman] speculates that Robert Woodhead's Virex application
takes a more conservative approach than Interferon, and does not worry
about identifying new viruses, under the generic term "Sneak".

While I do no use Virex, it is my understanding that it does try the
same trick as Interferon, and identify suspicious code as a "sneak"
virus.

As also stated previously, there is no virus known as "sneak" per se.
This is a term Woodhead alone uses to discuess new viruses that his
applications are not familiar with.

------------------------------

Date:    07 Nov 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Where are the Sophisticated Viruses?

In reply to a posting of mine, [e-mail] (jim frost) writes

> Sigh.  We're lucky that no very competent programmer has tried to
> write a virus, all right.

and goes on to give examples of some nasty things that future
viruses/worms might do.  His item is interesting and welcome;
I'm not clear, though, in what sense it's a reply to mine, or
what the "sigh" means.   In the posting that Mr. Frost is
quoting from, I was just replying to the original assertion
that current tools would not be able to detect a virus that
bypassed the operating system to talk directly to the hardware,
by pointing out that one class of tool that's common today
would not be fooled by that approach.  I certainly didn't
mean to suggest that there aren't *other* clever things
that viruses could do, but haven't yet done.

DC

------------------------------

Date:    Tue, 07 Nov 89 10:06:33 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Macwight Virus (?)

Is there such a beast?  Shuld I add it to the current list I have of
KNOWN viruses?  There is plenty of room now that I have deleted
"SNEAK" and "San Jose" from the list.  Thanks for the clarification.

P. S.  If anyone has a history of Macwight, if it exists, please forward
me a copy. Thanks again.

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Tue, 07 Nov 89 10:13:28 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Reviewing a Virus Article

I apologize for posting this request again.

I am writing an article for our computing newsletter and if anyone
would care to review it (if OK with Ken I can post it when finished) I
would welcome the critiques.  The only catch is that I must have the
reviews back NO LATER THAN 13 November.  If interested please send me
your address.

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
FAX:  [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Tue, 07 Nov 89 11:45:17 -0500
From:    Jason <[e-mail]>
Subject: Virus List (MAC)

I try to keep up with the Macintosh virus arena, but I've never heard
of the Dukakis virus.  Could someone please summerize some information
on what it is, where it started, and what it does?

Thank you,

=From the desk of: *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
*  Jason D. Blue                          =  User Services                  *
=  User Support Center Specialist         *  The MITRE Corporation          =
*  [e-mail]                 =  703-883-7999                   *
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Disclaimer:    The views expressed above are my own and do not reflect the
        position of my employer.

------------------------------

Date:    Tue, 07 Nov 89 12:33:07 -0500
From:    [e-mail]
Subject: TROJAN Horse by the name of NORTSTOP (PC)

From: Mr. J. Vavrina,   Intel & Sec Div, Automation Branch
Subject: TROJAN Horse by the name of NORTSTOP (PC)
I received this message via Ham Radio.

Path: K4NGC!W3IWI!WA4ONG!WB0TAX!WA2PVV
Date: 05 Nov 89 03:06:20 Z
From: WA2PVV@WA2PVV
To: KA4USE
Subject: Found This On My System

There is a file going around called either NORTSTOP.ZIP or NORTSHOT.ZIP
which, by it's (sparse) documentation and the copyright inside the EXE
file, claims to be from Norton Computing.  Because of the sparse and
unprofessionally presented docs, I looked within the EXE file and found:

  The Norton Public Domain Virus Utility,  PD Edition 5.50,  (C)1989
  Peter Norton

     Your System has been infected with a Christmas virus!  Selected
     files were just eliminated!  Without these files, you might as well
     use your computer as a damn, boat anchor!  If you do NOT own a
     boat, you may want to replace the files which were just erased.
     Try to determine which files they were.  HARDY  HA! HA! HA! HOW DO
     YOU FEEL NOW; YOU IDIOT?   MERRY CHRISTMAS AND HAPPY NEW YEAR!

===================
PKUNZIP reports:

 1065  Implode    650  39%  10-04-89  12:26  9778978d --w  READ-ME.NOW
38907  Implode  30156  23%  10-02-89  11:57  c333dec0 --w  NORTSHOT.EXE
- -----          ------  ---                                 -------
39972           30806  23%                                       2

I spoke with Craig and Tony from Norton Computing and it sure ain't
their's.  I DID run McAfee's SCANV on it, and it came up empty, so
either SCANV simply can't recognize it, or it's a prank, but either way,
it has no business being in circulation.  Be on the look out!

     To: ALL
   From: TONY MCNAMARA
   Subj: Trojan Horse

    We at Peter Norton Computing would like to bring to your attention
an unauthorized trojan horse named NortStop.ZIP or NortShot.ZIP (these
files are the same).  This file was NOT produced with the knowledge or
permission of PNCI.

    This file is not a virus (it does not infect files).  Instead, it
is a trojan horse (it must be run explicitly to cause any damage).
When run, it lists the directory and claims the system is virus-free.
Between December 24th and December 31st, however, it will erase files
in several directories based on their extensions.

    These files can be recognized by their sizes (NortStop.ZIP is
31744 bytes, NortStop.EXE is 38907 bytes), or by doing a text search
for the strings "NORTSHOT.EXE" in the ZIP, "Norton Public" in the EXE.

    If you find or hear of these files, please contact us immediately
through Tony McNamara, 213/319-2076 (voice), TMCNAMARA 381-9188 (MCI),
or CompuServe (72477,2504).

    Again, these files are in no way associated with PNCI.  Please
help us track down and eliminate these files.

    Thank you,

        Peter Norton


************** From the Desk of Mr. James M. Vavrina **************
*            Comm 703-355-0010/0011  AV 345-0010-0011             *
*                  DDN [e-mail]                  *
*******************************************************************

------------------------------

Date:    Mon, 06 Nov 89 13:19:08 -0500
From:    Arthur Gutowski <[e-mail]>
Subject: Previously reported BootChek problems (PC)

Regarding a previous couple of postings about problems with BootChek,
it appears that the problem is not a bug.  Evidently, Jeff has indeed
been hit by a virus or system problem of some kind.  After re-SYSing
the hard drive (from a clean system), and reinstalling BootChek, Jeff
says things are back to normal.  Since from the information I've obtained,
it doesn't seem to be bug-related, we (McConachie Associates--sorry John,
but it does have a ring to it) are looking at the other possibilities
(maybe a virus? or a system quirk?).  More info to come later.

I perhaps jumped the gun crying "bug", but hey, my experience as a programmer
has taught me to there is only one valid assumption about computing:
It's my fault.  Murphy's Law works in strange ways...

Arthur J. Gutowski,
Co-Author of BootChek
and
+--------------------------------------------------------------------+
| Antiviral Group / Tech Support / WSU University Computing Center   |
| 5925 Woodward; Detroit MI  48202; PH#: [phone]              |
| Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]       |
+====================================================================+
| Rules to live by, #153:                                            |
|   Never get caught on the wrong side of a Doppler shift.           |
+--------------------------------------------------------------------+

- ------- End of Forwarded Message

------------------------------

Date:    07 Nov 89 20:01:02 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Virus source available in Toronto

Sorry about the fact you got hurt personally out there in the
hinterlands...  I should have classified my statement even further...
the published "CURRENT" sources are not really that much of a threat
to a person experienced in counter- measures against viruses(READ Safe
Computing Practices...) and like it or not until more effective
protection is put into the silicon itself.. the watchword of the
future is be prepared carry computer condoms!!While any virus can be
deadly to the unprepared every one of the current day viruses that the
CVIA and other organizations and individuals has had the chance to
analysize... has been of the short fuse variety... this makes them
relatively easy to detect...  much greater damage can be done to the
security of an organization or a country by using viral techniques to
put covert data channels into place... these and other tricks will be
the next generation of virii...as far as the present day ... we will
always see relatively primitive virii being produced from published
\sources... as the publication usually lags the industry by as much as
several months it gives vendors who are in tune to this problem
several man months of r+d Time for new nostrums... I agree that while
some damage is done by sources but robert morrises type doesnt work
from published sources...  they usually have the skills necessary to
bypass that!!About the only sophisticated technique i have seen was in
traceback....all else was just standard dos/bios System programming
skills needed to implement...the biggest leg up to a budding virii
developer are the tsr programming packs with source and various
articles and tools on reverse code engineering...so sorry to poke
holes in your favorite theorys but we havent seen or detected any more
than annoyance viruses from published sources ghost viruses not
withstanding...(again I will reiterate for the computer \user
unwilling to make the commitment in time and energy to become
knowledgeable about safe computer practices these viruses can indeed
be deadly but enough sources have been released at this point that the
genie really cant be put back in the bottle(I too wish it hadnt
happened... but it did and now we have to learn to live with and treat
the problem... just like aids in the bay area... one is either
knowledgeable or one will be eventually dead!!) same for computers one
will either be knowledgeable or...  some idiot there will release a
virus and throw ones data in the bit bucket...  As far as the
unsophisticated user who wants to protect well thats what CVIA is
there for...
           cheers
           kelly
p.s. sorry guy but I dont take a hand wringing approach to the problem
of published sources...mostly every thing I have seen so far is on a
relatively primitive level... i.e. no 1-way decryption... no shadow
allocation systems...  no memory residence being done by techniques
which totally bypass dos and any existing antiviral products...no PSP
backtracing and use of obsolete ways into dos!!in other words nothing
much more than present day leading edge tools can protect against!!it
could easily be a far far worse situation if various government
"black" organiztions and/or terrorists and/or Corporate IE (Industrial
Espionage) types were to fund underground virus developement for
unknown neferious goals ....

------------------------------

Date:    07 Nov 89 20:26:46 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Where are the Sophisticated Viruses?

Jesus you mean someone else out there can think for himself...as far
as what you said 100% concurrence...it would turn most even tech types
pale to see what a "guru" could put together... fortunately most to
date have been of the relatively non-malicious variety...(gurus that
is) I work locally here in Silly-Con valley as a Network nerd and
various wizard on\ a extremely broad swath of tech areas... anti-viral
lab work is a VERY large part of that... I am running 386/pcdos only
in protected mode with several layers of antiviral products... my
write lines on my drive interfaces have to be explicitly and manually
enabled...VM/8086 partitions are used to block direct access to REAL
Memory or IO PORTS (And I even feel nervous telling the entire
readership of this newsgroup that much) I also encrypt my disks... I
cant endorse any products publicly but certain products are a definite
step above others...also incrementally backup in the background at
extremely frequent intervals AND even I can be HIT
Sucessfully..........!!!  my net seems to be 99% sucessful so far but
knock on wood!!!
          cheers
          kelly


------------------------------

Date:    Tue, 07 Nov 89 17:09:00 -0600
From:    [e-mail]
Subject: need disinfection info for BRAIN virus (PC)

In using Viruscan (version 4.8) the scan found PAKISTANI/BRAIN/ASHAR
virus on a number of student diskettes.  I check the Homebase BBS and
didn't find a disinfection program for these strains.  Can anyone
suggest a disinfection program and if there's one on the network that I
can get?  Is running a disinfection program the solution to this/these
viri??

Thanks....
Neta Counts

------------------------------

Date:    Tue, 07 Nov 89 19:06:28 -0600
From:    [e-mail] (Vince Laurent - work id)
Subject: WARNING: Brain virus infection (PC)

Our Computer Centers have been blessed with the return of (c)Brain. We
also have recorded cases of the Jerusalem B virus. Both of these have
been found by the VIRUSCAN program that was given to our Computing
Information Center.  I have a VACCINE program for (c)Brain but is
there one for the other virus and if so where do I get it or can
someone send it to me? Thanks in advance...

                        ---------------------------------------------
                        | Vincent J. Laurent                        |
                        | Computing Information Center &            |
                        |             Computer Learning Center 1    |
                        | Southern Illinois University - Carbondale |
                        | CA6692@SIUCVMB                            |
                        ---------------------------------------------

------------------------------

Date:    Tue, 07 Nov 89 16:31:22 +0000
From:    biar![e-mail] (Robert J Woodhead),
         [e-mail] (Robert J Woodhead)
Subject: Re: Virus List - Notes (Mac)


[e-mail] (Joe McMahon) writes:

>This was simply a convenient name for a particular virus-like code
>pattern that Bob Woodhead's "Interferon" program looked for - for
>those who are interested, an immediate branch out of CODE 0 to some
>other CODE segment.  There is no specific virus called SNEAK, and
>there never has been.

No, what you are describing is the infamous Interferon Anomaly 104.
The infection strategy I described as ``sneak'' was changing the
type of a common System folder file to INIT.  This check was too
rigorous and gave false positives when System 6.0 came out because
in 6.0 some of the file types changed.

You are right : there is no such thing as SNEAK.  And Interferon is
obsolete now; use Disinfectant or (plug, plug) Virex.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!


------------------------------

Date:    Tue, 07 Nov 89 22:58:00 -0500
From:    [e-mail]
Subject: excerpts from risks-l digest

Following are two excerpts from RISKS-L digest.  Enjoy, Cl.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes     HAYES @ URVAX                 (Vanilla BITNET)
University of Richmond   [e-mail]     (Bitnet or Internet)
Richmond, VA  23173      ...!psuvax1!urvax.bitnet!hayes          (UUCP)

 --- begin forwarded message ---

RISKS-LIST: RISKS-FORUM Digest  Tuesday 7 November 1989   Volume 9 : Issue 39

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
* Computer Viruses Attack China (Yoshio Oyanagi)
* First Virus Attack on Macs in Japan (Yoshio Oyanagi)

Date: Mon, 6 Nov 89 12:15:25+0900
From: Yoshio Oyanagi <[e-mail]>
Subject: Computer Viruses Attack China

     Ministry of Public Safety of People's Republic of China found this
summer that one tenth of the computers in China had been contaminated by
three types of computer virus:  "Small Ball", "Marijuana" and "Shell", China
Daily reported.  The most serious damage was found in the National
Statistical System, in which "Small Ball" spread in 21 provinces.
In Wuhan University, viruses were found in *ALL* personal computers.
     In China, three hundred thousand computers (including PC's) are
in operation.  Due to premature law system the reproduction of
software is not regulated, so that computer viruses can easily be
propagated.  Ministry of Public Safety now provides "vaccines" against
them.  Fortunately, those viruses did not give fatal damage to data.
                                   Yoshio Oyanagi, University of Tsukuba, JAPAN

 ------------------------------

Date: Tue, 7 Nov 89 17:07:09+0900
From: Yoshio Oyanagi <[e-mail]>
Subject: First Virus Attack on Macs in Japan

First Virus Attack on Macs in Japan

     Six Macs in University of Tokyo, Japan, were found to have caught
viruses, newspapers and radio reported.  Since this September, Prof. K. Tamaki,
Ocean Research Institute, University of Tokyo, has noticed malfunctions on the
screen.  In October, he applied vaccines "Interferon" and "Virus Clinic" to
find his four Mac's were contaminated by computer viruses, "N Virus" type A and
type B.  He then found ten softwares were also infected by viruses.  A Mac of
J. Kasahara, Earthquake Research Institute, University of Tokyo, was also found
to be contaminated by N Virus and Score Virus.  Those are the first reports of
real viruses in Japan.

     Later it was reported that four Mac's in Geological Survey of Japan, in
Tsukuba, were infected by N Virus Type A.  This virus was sent from U. S.
together with an editor.
                                        Yoshio Oyanagi, University of Tsukuba

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  8 Nov 1989    Volume 2 : Issue 236

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Introduction to the anti-viral archives
UNIX anti-viral archive sites
Apple II anti-viral archive sites
Atari ST anti-viral archive sites
Amiga anti-viral archive sites
IBMPC anti-viral archive sites
Documentation anti-viral archive sites
Macintosh anti-viral archive sites
New anti-virus files uploaded to SIMTEL20 (PC)
Re: Where are the Sophisticated Viruses? (PC)

---------------------------------------------------------------------------

Date:    08 Nov 89 05:19:49 +0000
From:    [e-mail] (Jim Wright)
Subject: Introduction to the anti-viral archives

# Introduction to the Anti-viral archives...
# Listing of 07 November 1989

This posting is the introduction to the "official" anti-viral archives
of virus-l/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

Jim

==== cruft for the lawyers ====

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.  Unfortunately, in this day and age nothing is certain.  It is awful
that these people have to worry about legalities when they are only trying
to provide a free and useful service.  But facts are facts.  Your use of
the archives relieves the sites from any liability.

Sigh.

------------------------------

Date:    08 Nov 89 05:20:49 +0000
From:    [e-mail] (Jim Wright)
Subject: UNIX anti-viral archive sites

# Anti-viral and security archive sites for Unix
# Listing last changed 30 September 1989

attctc
        Charles Boykin <[e-mail]>
        Accessible through UUCP.

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

sauna.hut.fi
        Jyrki Kuoppala <[e-mail]>
        Accessible through anonymous ftp, IP number 128.214.3.119.
        (Note that this IP number is likely to change.)

ucf1vm
        Lois Buwalda <[e-mail]>
        Accessible through...

wuarchive.wustl.edu
        Chris Myers <[e-mail]>
        Accessible through anonymous ftp, IP number 128.252.135.4.
        A number of directories can be found in ~ftp/usenet/comp.virus/*.

------------------------------

Date:    08 Nov 89 05:18:15 +0000
From:    [e-mail] (Jim Wright)
Subject: Apple II anti-viral archive sites

# Anti-viral archive sites for the Apple II
# Listing last changed 30 September 1989

brownvm.bitnet
        Chris Chung <[e-mail]>
        Access is through LISTSERV, using SEND, TELL and MAIL commands.
        Files are stored as
                apple2-l xx-xxxxx
        where the x's are the file number.

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Apple II index for the virus archives can be retrieved as
                request: apple
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.


------------------------------

Date:    08 Nov 89 05:18:37 +0000
From:    [e-mail] (Jim Wright)
Subject: Atari ST anti-viral archive sites

# Anti-viral archive sites for the Atari ST
# Listing last changed 30 September 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Atari ST index for the virus archives can be retrieved as
                request: atari
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>.

panarthea.ebay
        Steve Grimm <[e-mail]>
        Access to the archives is through mail server.
        For instructions on the archiver server, send
                help
        to <[e-mail]>.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.


------------------------------

Date:    08 Nov 89 05:17:51 +0000
From:    [e-mail] (Jim Wright)
Subject: Amiga anti-viral archive sites


# Anti-viral archive sites for the Amiga
# Listing last changed 30 September 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Amiga index for the virus archives can be retrieved as
                request: amiga
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

ms.uky.edu
        Sean Casey <[e-mail]>
        Access is through anonymous ftp.
        The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
        The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

uxe.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        Lionel Hummel <[e-mail]>
        The archives are in /amiga/virus.
        There is also a lot of stuff to be found in the Fish collection.
        The IP address is 128.174.5.54.
        Another possible source is uihub.cs.uiuc.edu at 128.174.252.27.
        Check there in /pub/amiga/virus.


------------------------------

Date:    08 Nov 89 05:19:26 +0000
From:    [e-mail] (Jim Wright)
Subject: IBMPC anti-viral archive sites

# Anti-viral archive for the IBMPC
# Listing last changed 30 September 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The IBMPC index for the virus archives can be retrieved as
                request: ibmpc
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

ms.uky.edu
        Daniel Chaney <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus.
        The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

uxe.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pc/virus.
        The IP address is 128.174.5.54.

vega.hut.fi
        Timo Kiravuo <[e-mail]>
        This site (in Finland) can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pub/pc/virus.
        The IP address is 128.214.3.82.

wsmr-simtel20.army.mil
        Keith Peterson <[e-mail]>
        Direct access is through anonymous ftp, IP 26.2.0.74.
        The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
        Simtel is a TOPS-20 machine, and as such you should use
        "tenex" mode and not "binary" mode to retreive archives.
        Please get the file 00-INDEX.TXT using "ascii" mode and
        review it offline.
        NOTE:
        There are also a number of servers which provide access
        to the archives at simtel.
        WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
        from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
        from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
        (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
        are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
        DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
        EB0UB011 (Spain) and TREARN (Turkey).


------------------------------

Date:    08 Nov 89 05:18:59 +0000
From:    [e-mail] (Jim Wright)
Subject: Documentation anti-viral archive sites

# Anti-viral archive sites for documentation
# Listing last changed 30 September 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The index for the **GENERAL** virus archives can be retrieved as
                request: general
                topic: index
        The index for the **MISC.** virus archives can be retrieved as
                request: misc
                topic: index
        **VIRUS-L** entries are stored in monthly and weekly digest form from
        May 1988 to December 1988.  These are accessed as log.8804 where
        the topic substring is comprised of the year, month and a week
        letter.  The topics are:
                8804, 8805, 8806 - monthly digests up to June 1988
                8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests
        The following daily digest format started on Wed 9 Nov 1988.  Digests
        are stored by volume number, e.g.
                request: virus
                topic: v1.2
        would retrieve issue 2 of volume 1, in addition v1.index, v2.index and
        v1.contents, v2.contents will retrieve an index of available digests
        and a extracted list of the the contents of each volume respectively.
        **COMP.RISKS** archives from v7.96 are available on line as:
                request: comp.risks
                topic: v7.96
        where topic is the issue number, as above v7.index, v8.index and
        v7.contents and v8.contents will retrieve indexes and contents lists.
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

lehiibm1.bitnet
        Ken van Wyk <[e-mail]> new: <[e-mail]>
        This site has archives of VIRUS-L, and many papers of
        general interest.
        Access is through ftp, IP address 128.180.2.1.
        The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

unma.unm.edu
        Dave Grisham <[e-mail]>
        This site has a collection of ethics documents.
        Included are legislation from several states and policies
        from many institutions.
        Access is through ftp, IP address 129.24.8.1.
        Look in the directory /ethics.


------------------------------

Date:    08 Nov 89 05:20:23 +0000
From:    [e-mail] (Jim Wright)
Subject: Macintosh anti-viral archive sites

# Anti-viral archive sites for the Macintosh
# Listing last changed 07 November 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Mac index for the virus archives can be retrieved as
                request: mac
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

ifi.ethz.ch
        Danny Schwendener <[e-mail]>
        Interactive access through DECnet (SPAN/HEPnet):
                $SET HOST 57434  or $SET HOST AEOLUS
                Username: MAC
        Interactive access through X.25 (022847911065) or Modem 2400 bps
        ([phone]):
                # CALL B050 <cr><cr>
                Username: MAC
        Files may also be copied via DECnet (SPAN/HEPnet) from
                57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
        Werner Uhrig <[e-mail]>
        Access is through anonymous ftp, IP number is 128.83.144.1.
        Archives can be found in the directory mac/virus-tools.
        Please retrieve the file 00.INDEX and review it offline.
        Due to the size of the archive, online browsing is discouraged.

scfvm.bitnet
        Joe McMahon <[e-mail]>
        Access is via LISTSERV.
        SCFVM offers an "automatic update" service.  Send the message
                AFD ADD VIRUSREM PACKAGE
        and you will receive updates as the archive is updated.
        You can also subscribe to automatic file update information with
                FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
        Bill Lipa <[e-mail]>
        Access is through anonymous ftp, IP number is 36.44.0.6.
        Archives can be found in /info-mac/virus.
        Administrative queries to <[e-mail]>.
        Submissions to <[e-mail]>.
        There are a number of sites which maintain shadow archives of
        the info-mac archives at sumex:
        * MACSERV@PUCC          services the Bitnet community
        * LISTSERV@RICE         for e-mail users
        * FILESERV@IRLEARN      for folks in Europe

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

wsmr-simtel20.army.mil
        Robert Thum <[e-mail]>
        Access is through anonymous ftp, IP number 26.2.0.74.
        Archives can be found in PD3:<MACINTOSH.VIRUS>.
        Please get the file 00README.TXT and review it offline.


------------------------------

Date:    Wed, 08 Nov 89 01:15:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: New anti-virus files uploaded to SIMTEL20 (PC)

I have uploaded the following files to SIMTEL20:

pd1:<msdos.trojan-pro>
SCANRS48.ARC    Resident program to scan for many viruses
SCANV48.ARC     VirusScan, scans disk files for 48 viruses

SCANRS48 and SCANV48 were downloaded from the Homebase BBS.

- --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    08 Nov 89 11:23:12 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Where are the Sophisticated Viruses? (PC)


jim frost writes:
>Limiting Propagation Rates.

Some viruses do this. SysLock, Icelandic and Typo-COM will only infect some
of the programs they have a chance to infect. They use different methods,
like "only every other day" or "only every tenth program run".

>Limiting Re-Infections.  Most simple viruses don't detect systems
>which have already been infected and will re-infect them.

Actually very few viruses infect the same "victim" over and over. Some boot
sector viruses do, but the only program virus which does so is the original
version of the Israeli (Jerusalem) virus.

>
>Detecting and Avoiding "Virus-Protected" Hosts.  I have yet to see a
>virus which looked at the state of a system to detect virus detection
>mechanisms to nullify them and/or avoid infecting them.

One virus - the "Icelandic" virus - makes an attempt at this. It will not
infect a system if it determines that any program has hooked INT 13. Since
all virus monitoring programs do that, it will not be detected by them.
(In practice this does not work too well, because of a bug in the code..)

>Staying Within Normal System Activity Boundaries.

Most resident viruses do this.

>Hiding From Standard System Utilities.

This is the difficult part. Very few existing viruses are able to do this
properly. Most boot sector viruses will decrease the amount of memory
available - for example turning a 640K machine into a 639K one. Program
viruses can in many cases be detected by using a ordinary memory mapping
utility. Still, quite a few manage to hide even from that, but there is room
for much improvement in this area :-(

>Modifying Hosts To Make Them More Susceptible To Re-Infection.

This brings up the topic of "virus types we have not seen yet". I have
written a document describing a few types of viruses that could theoretically
be written, but are currently unknown. Description of one of the types
follows.

   7) The "AIDS" type. This type of virus is very dangerous. Not because
      it destroys programs or data, but because it attacks the protection
      mechanism in the computer. These viruses can be divided in two
      subgroups.

         Specific:  These viruses will search for known anti-virus programs
                    and disable or destroy them. They might to that by
                    patching the code in memory and then overwriting parts
                    of the protection programs on the disk.

         General:   These viruses must be much more complicated, but they
                    could for example try to determine what programs had
                    hooked a specific interrupt. Then they might modify
                    a few memory locations in order to bypass those programs.

      A virus of this type might not do any further damage, but it would
      leave the system vulnerable to attacks by other viruses, which might
      then have a devastating effect.

>By now you should get the idea that almost every virus we've seen is
>primitive, although several showed some of the survival traits which I
>outline above.  Given the limited resources of PC environments, it's
>unlikely that you'll get a very sophisticated virus.

I must disagree. In the PC environment it is not a question of limited
resources, but rather the fact that any user process has full access to
ALL resources and can even directly manipulate the hardware if required.
So, my opinion is that it is even easier to write a sophisticated virus on
the PC than in most other environments.

Finally, I want to add one "feature" to the description of a sophisticated
virus:

"Bypass protection programs and jump directly to the hardware, DOS or
BIOS routines."

There are quite a few "filter" programs available that will monitor every
INT 13, INT 21, INT 40.... call and alert the user if an attempt is made
to do an illegal operation. They are, however, almost useless against
viruses that can access the system directly in the way described above.

Only two or three viruses do this now, but I am certain that more virus
writers will figure out how to do this in the future. :-(

- -frisk

         Fridrik Skulason          University of Iceland
         [e-mail]           Computing Sevices

          Guvf yvar vagragvbanyyl yrsg oynax .................

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday,  9 Nov 1989    Volume 2 : Issue 237

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Where are the Sophisticated Viruses?
Chinese Viruses
Re: Macwight Virus (?)
Jerusalem virus (PC)
virus problem undecidability
KillVirus INIT (Mac)
Re: Macwight Virus (?)
MacWight? (Mac)
Dukakis Virus (Mac)
RE: future viruses on a PC Pull plug before cleaning

---------------------------------------------------------------------------

Date:    Wed, 08 Nov 89 13:15:35 +0000
From:    [e-mail] (Christer Ericson)
Subject: Re: Where are the Sophisticated Viruses?

In article <[e-mail]> ctycal![e-mail]
ry.ca writes:
>There are probably two reasons why the viruses you suggest do not
>exist:
>  1) If the system code is bypassed, then it must be rewritten.
>     Most hackers are not at that level.  Those that are that
>     proficient are busy making money.
>  2) Code to do all the stuff needed would be quite large, and
>     therefore noticeable.  If you add 20 K to somebody's
>     programs they will likely notice.

I don't agree with you on any of these points, Terry. Say, on the
Macintosh all calls to ROM are done through trap vectors in RAM. These
trap vectors are patched by the system file (to fix bugs), by some
programs and by all anti-virus tools. However, it doesn't take a
genius to figure out that one could restore the trap vector to it's
original value and thereby bypassing the "safe" system.  (Alright, we
don't have the bug fixes installed, but it's easy to mimic what is
done by the system file. (For instance by simply calling the very same
routine.)). A patch like this wouldn't occupy much space and is quite
simple to write.

I'd guess I could write a virus using the above technique in a day or
two, which would be undetectable by all existing anti-virus tools, and
along with me so could lots of other people. However some of us are
busy making money, as you said, and we who are just working (:-))
probably have some sense of moral, stopping us from bringing total
chaos to the computer society.

>  Terry Ingoldsby

/Christer

| Christer Ericson                           Internet: [e-mail]  |
| Department of Computer Science, University of Umea, S-90187 UMEA, Sweden |
|     >>>>>    "I bully sheep. I claim God doesn't exist..."    <<<<<      |

------------------------------

Date:    Wed, 08 Nov 89 13:20:38 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Chinese Viruses

I just saw a note on comp.risks about viruses in China.

>     Ministry of Public Safety of People's Republic of China found this
>summer that one tenth of the computers in China had been contaminated by
>three types of computer virus:  "Small Ball", "Marijuana" and "Shell", China
>Daily reported.

The "Small Ball" is probably just a variant of Ping-Pong, "Marijuana" is
the same virus as "Stoned" or "New Zealand", but what is "Shell" ??

Anybody got an idea ?

- -frisk

------------------------------

Date:    Wed, 08 Nov 89 12:08:20 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Macwight Virus (?)

In Virus-L V2 #235, "Gregory E. Gilbert" <[e-mail]> asks
about the "Macwight" (sic) virus.

Recently, there was a report of a virus that attacked MacWrite from
the University of Rochester.  Since the initial report however,
nothing has been heard from them.

------------------------------

Date:    Wed, 08 Nov 89 11:54:42 -0600
From:    [e-mail] (Chris Beckenbach)
Subject: Jerusalem virus (PC)

The Jerusalem virus has turned up here at Southern Illinois
University, also.  From dissecting a copy of the virus, and an article
in the February 15, 1989 edition of Datamation ("The Virus Cure", by
John McAffe, Pp. 29-40), the Jerusalem virus (called the Israeli virus
in the Datamation article) does the following:

When an infected .EXE or .COM file is loaded and run, the Jerusalem
virus checks to see if it is already resident in the computer.  If
not, it sets itself up to intercept DOS INT 21h, then proceeds to run
the infected program normally.  Whenever a call is made to INT 21h to
execute a program (function 4Bh), the virus will append itself to the
program file on the disk and set itself up as the entry point for that
program.  This adds 1808 bytes of length to the file, but does not
change the time/date stamp.  If the disk is write-protected, no error
will be given, and the file will not be infected.  The copy of the
virus that I have been looking at infects .EXE files multiple times
(the Datamation article says that this is a bug that has been "fixed"
by hackers in other versions), so usually the major problem with this
virus will be that it will waste memory and disk space.  John McAfee's
article also says that this multiple infection does not occur with
.COM files, but I have not verified this.  The most serious aspect of
this virus is that when the system date is Friday the 13th (except
when the year is 1987--this virus was first discovered in 1987, so
this was probably written in to give it time to spread) any call to
execute a .COM or .EXE file will result in the file's being deleted
from the disk.

I have been informed that Flushot will take the virus out of infected
programs, so if you have the virus and Flushot, you might want to try
this.

Hope this has been of help.

Chris Beckenbach              ST7751@SIUCVMB
Computer Science major        Southern Illinois University
Carbondale, Illinois

        "I think, therefore I think I am--I think."

------------------------------

Date:    Wed, 08 Nov 89 16:32:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: virus problem undecidability

A note to the virus-l digest of 6-Nov-89 said that "the virus problem (at
least detection anyway) is undecidable."  Does anyone know if there are
any papers where this result is proved? Or where the problem is
shown to not be NP complete? Or even where the problem is stated
precisely?

Thanks,
Peter Day
Emory University

------------------------------

Date:    Wed, 08 Nov 89 17:04:50 -0500
From:    Joe McMahon <[e-mail]>
Subject: KillVirus INIT (Mac)

Yes, the KillVirus INIT contains a "dummy" nVIR resource which it will
attempt to install into the System file. This resource will trigger
most less-sophisticated virus detectors. In addition, KillVirus is
supposed to be able to automatically uninfect files infected with the
A strain of nVIR. I haven't tested this, but I wouldn't want to bet
the farm on it.

 --- Joe M.

------------------------------

Date:    08 Nov 89 22:41:56 +0000
From:    [e-mail] (The Mad Mathematician)
Subject: Re: Macwight Virus (?)


In article <[e-mail]> C0195%UNIVSCVM.BITNET@VMA.C
C.CMU.EDU (Gregory E. Gilbert) writes:
>Is there such a beast?

Macwight is a name someone here at the U of R gave to an error we
found in a few copies of Macwrite.  Something or someone changed the
icon of Macwrite to show the word Macwite instead of the lines, and
the name of the the application to Macwite or Macwight.  After the
first few reports, I got a copy to play with for a while, but it was
taken and given to someone else.  Since then I haven't seen another,
nor have any of the student consultants.  I don't know if this was a
true virus, but it a copy of Macwrite changed before the consultant's
boss' eyes, ie the name changed from Macwrite to Macwite, and upon
inspection via Resedit the icon was found to have changed.

>Gregory E. Gilbert

The Mad Mathematician
[e-mail]
Mad, adj.  Affected with a high degree of intellectual independence.
    Ambrose Bierce, _The_Devil's_Dictionary_

------------------------------

Date:    Wed, 08 Nov 89 18:17:21 -0500
From:    Joe McMahon <[e-mail]>
Subject: MacWight? (Mac)

You may (or may not :-) remember the discussions we had here on the
list about this. As far as I remember, there was never a specific
demonstration that there was a virus involved. That doesn't mean that
there wasn't; it just means that there were never quite enough facts
presented to make a case either way. I'd leave it off for now, or
mention it as a "rumored sighting" or whetever. Safest not to mention
it, especially since it was never pinned down and analyzed.

 --- Joe M.

------------------------------

Date:    Wed, 08 Nov 89 18:20:42 -0500
From:    Joe McMahon <[e-mail]>
Subject: Dukakis Virus (Mac)

The "Dukakis Virus" was a self-perpetuating HyperCard script. When the
stack containing it was opened, it would first try to install itself
into the Home stack. The version in the Home stack would then spread
to other stacks.  Editing it out of the Home stack and installing an
"ON SET" script was sufficient to block it.

It was released on CompuServe and apparently was not set up to have a
long enough incubation time before it first went off. I believe it was
stamped out pretty quickly, but it did exist.

Worst, the actual script was published in the InfoMac digest...

 --- Joe M.

------------------------------

Date:    Wed, 08 Nov 89 22:40:00 -0600
From:    "David Richardson, UTA" <[e-mail]>
Subject: RE: future viruses on a PC Pull plug before cleaning

[e-mail] writes
>jim frost writes:
>>Limiting Propagation Rates.
[edited out list of viruses that limit propogation rates]
[frost goes on to point out how some of todays viruses meet some criteria
 of the "ultimate virus", and mentions the threat of AIDS and other
 anti-disinfecting viruses]

>>By now you should get the idea that almost every virus we've seen is
>>primitive, although several showed some of the survival traits which I
>>outline above.  Given the limited resources of PC environments, it's
>>unlikely that you'll get a very sophisticated virus.
>
>I must disagree. In the PC environment it is not a question of limited
>resources, but rather the fact that any user process has full access to
>ALL resources and can even directly manipulate the hardware if required.
>So, my opinion is that it is even easier to write a sophisticated virus on
>the PC than in most other environments.

The PC user has one weapon that is impactical on a mainframe:
THE PC USER CAN TURN OFF HIS MACHINE AT ANY TIME AND DISINFECT HIS SYSTEM
VERY EASILY.  NO VIRUS (THAT I KNOW OF) CAN LIVE THROUGH A COLD BOOT.

As long as PCs retain an OFF switch, then we have the ultimate power over
our compters, viruses or not.

- -David Richardson   [e-mail], @utarlg.arl.utexas.edu
UTSPAN::UTADNX::UTARLG::B645ZAX             phone [phone]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 10 Nov 1989    Volume 2 : Issue 238

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Sophisticated Viruses
Re: Sophisticated Viruses
386 Isolation
Pam Kanes book and the CVIA
Undecidability
RE: MacWight dilemma (Mac)
Details of Ogre, Dark Avenger, etc. (PC)
Another attack?!? (PC)
Re: Sophisticated Viruses?
Re: Checksum programs; Hardware protection
Ping Pong virus (PC) at UIUC
Re: virus problem undecidability
New IBMPC anti-virals
Re: future viruses on a PC Pull plug before cleaning
In Search Of Virus Info

[Ed. In an effort to send out one digest per day, this digest is
longer than usual.  If anyone has truncation problems due to its
length (~32k), please let me know.]

---------------------------------------------------------------------------

Date:    Thu, 09 Nov 89 09:59:00 -0500
From:    [e-mail]
Subject: Sophisticated Viruses

Thanks to Jim Frost for a very thought provoking posting.  Here are some
that I had while reading it.

>Limiting Propagation Rates.  Simple viruses, and often not-so-simple
>ones, will proliferate without bounds.  Rampant proliferation will
>cause the virus to be noticed early in its lifetime and will probably
>lead to its early demise.  The internet worm did not do this.

Most PC viruses do not do it either.  When the vector is a diskette,
it need not.  Most of the network worms have not done it; they wanted
to be noticed.  Therefore, the requirement is a function of both the
chosen vector and the motive.

>Detecting and Avoiding "Virus-Protected" Hosts.  I have yet to see a
>virus which looked at the state of a system to detect virus detection
>mechanisms to nullify them and/or avoid infecting them.

Biological viruses simply ignore potential but immune hosts.  If the
potential population is sufficiently large, the presence of immune
subjects is not important.

However, again motive is important.  We have not seen any viruses that
were determined to conceal their existence, in part because writing a
virus that no one notices is not any fun.  If no one notices, then
it is not possible to know about propagation or survival.  What fun is
that?

>Count our blessings now because you
>won't believe how bad tomorrow's nightmares will be unless we start
>teaching ethics to tomorrow's programmers!

I will settle for simple self interest.  ALL computer users have a
vested interest in an orderly environment in which programs can be
relied upon to do only what they advertise.  Virus writers are soiling
their own nests.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 09 Nov 89 10:37:36 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Re: Sophisticated Viruses

[e-mail] writes:

>> We have not seen any viruses that were determined to conceal their
>> existence...

In theory anyway, what proof to we have of their non-existence?  If
they're determined to conceal themselves, then why would we expect to
notice them in the first place?

In Cliff Stoll's book, "The Cuckoo's Egg", Dr. Stoll points out that
for every forty (approximately) computers that the hacker invaded,
only one or two system administrators ever noticed.  The connections
were relatively overt in that they left behind audit trails ('lastlog'
entries), yet very few people noticed.  (In my personal opinion, by
the way, "The Cuckoo's Egg" should be considered required reading by
anyone who runs, or is interested in, computers - *highly*
recommended.)

>> ...in part because writing a virus that no one notices is not any
>> fun.  If no one notices, then it is not possible to know about
>> propagation or survival.  What fun is that?

There's an important distinction to be made here - detection during
propagation vs. detection after (presumably) successful propagation.
A virus could well attempt to conceal its existence while propagating,
and then do quite the opposite (!) during a destructive phase.  No one
would notice until it would be too late.

I'm not trying to sound like the voice of gloom and doom, really.  I
don't believe that the sky is falling.  The purpose of this posting
isn't to sound sensationalistic - merely to raise some questions.

Ken van Wyk

------------------------------

Date:    Thu, 09 Nov 89 10:50:00 -0500
From:    [e-mail]
Subject: 386 Isolation

The isolation hardware in the I386 makes it possible to construct a
contained execution environment in which all the effects of execution
are contained within the envrionment.  Such an environment would be a
useful place to test untrusted programs.

Has anyone constructed such an environment?

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    08 Nov 89 02:38:45 +0000
From:    [e-mail] (Kelly Goen)
Subject: Pam Kanes book and the CVIA

Hi I am passing this note on for the CVIA... no endorsement is made nor
representation implied by Amdahl Corp or Onsite consulting as to the
information that follows:

   I am the Acting Technical Director of the National BBS Society and,
though I spend a great deal of time on computer virus related
activities, I am not an active participant in any of the virus
discussion forums, such as Virus-L.  I do keep current with important
virus issues and virus-related publications and occasionally come
across something that requires comment.  Pam Kane's book "V.I.R.U.S. -
Vital Information Resources Under Siege" from Bantam Books is one such
thing.
     Aside from the many technical inaccuracies and misleading product
information contained in the book, Pam Kane's portrayal of the
National BBS Society, the Computer Virus Industry Association and John
McAfee's involvement in each is highly charged and grossly fallacious.
Her assertion, for example, that Mr. McAfee 'owns' the National
Bulletin Board Society and controls its virus-related activities is
absurd to the point of comedy.  The claim that the donation of a
five-line bulletin board, months of unpaid time, and the
responsibilities of coordination for a loose-knit and highly
independent group of 2,000 SysOps is "ownership" cannot be taken
seriously.  Her entire discussion of the National Bulletin Board
Society shows a blatant disregard for the facts and an alarming lack
of understanding of the dynamics of virus research.
     More amazing, though, is her recollection of the events
surrounding the formation of the Computer Virus Industry Association,
an event that I witnessed first hand.  Ms. Kane would have us believe
that Mr. McAfee was strongly interested in having herself and other
small antiviral product vendors as members and went out of his way to
try and force membership on these companies.  My own recollection was
that Mr. McAfee extended these invitations out of politeness.  It is
hard to imagine why an organization that includes Microsoft, Lotus,
Novell, Boeing Computer Services, Amdahl, Locus, Fujitsu, Ford
Aerospace, Martin Marietta and 35 other such companies would be so
interested in having Panda Systems as a member.
     I asked for and received permission from Mr. McAfee to include
part of a May 2, 1988 letter from Mr. McAfee to Kate Drew-Wilkerson
describing his intent to form the CVIA.  I hope this puts his intent
in proper perspective:

"May 2, 1988

"Kate,
"    It is clear, at least to me, that computer viruses will not
go away of their own accord.  On the contrary, they must, based
on all known laws of statistics, increase in prevalence.  What we
see today is merely a shadow of the problems we will face in the
future.  The number of individual strains will increase at some
linear rate, and the incidences of infection will increase
geometrically.  This much is clear.  The time frame is the only
unknown.
"    Accordingly, I feel that the most urgent need is to
organize.  A consortium of hardware and software developers
focused on the unique problems posed by an impending rash of
infections is Priority One.  For this to work, we mustobviously
have the corporate computer industry leaders involved.  How to do
so at this juncture is the problem.  The companies that shape
the computer markets and policies have not yet been directly
impacted, and by and large they dismiss the issue.  In time this
will change.  For now, however, I will content myself with the
three or four security firms who have branched out into the
computer virus marketplace and with whom I have established a
rapport.  We can jointly form the foundations for the later entry
of the industry giants.
"   From a sense of responsibility, and to embark with the
necessary open forum required for success, I will extend an
invitation to all parties that are known to me to be active in
the virus field.  It is doubtful, however, given the existing
antagonism between the various vendors, that I shall have much
success at achieving a quorum.  In truth, I am counting on the
probability that those vendors who would prove embarrassing as
members will, for obvious reasons, decline participation.
...
"    /s/John McAfee"

     I would like to thank the moderator of this virus forum for
providing a means of voicing my viewpoints in what I feel is an
important computer virus area.

Aryeh Goretsky, Acting Technical Director
National BBS Society
1429 Dry Creek Road
San Jose, CA  95125-4617
408 265 8499

               Kelly Goen/ Cybernetic Systems Specialists Inc.

Disclaimer: neither Amdahl Corp nor Onsite consulting offer any
representation warranty or guarentees as to the accuracy of the
information in this e-mail.

------------------------------

Date:    Thu, 09 Nov 89 12:52:00 -0500
From:    "Joseph M. Beckman" <[e-mail]>
Subject: Undecidability

The hypothesis of viral detection is that it is an undecidable task to
determine whether an arbitrary program on an arbitrary "machine"
contains a virus or not.  This does not mean the viral detection
question is undecidable.

First, one is primarily interested in a subclass of the question.  This
subclass is a Type II error, or false acceptance (saying a program is
virus free when it is not).  Crocker & Pozzo have argued that it is
feasible to create a filter which has a Type II error rate of 0.
Naturally, some programs without viruses are rejected by a filter of
this type.  See their paper in the 1989 IEEE Security & Privacy
Conference Proceedings.

Second, neither programs nor machines are arbitrary in the real world.
One can certainly think of machines (and then of programs running on
those machines) where it can be trivially and without error shown
whether a particular program is infected with a virus or not.

All of this assumes that one has a definition of "virus."

Joseph

------------------------------

Date:    Thu, 09 Nov 89 12:49:00 -0500
From:    <[e-mail]>
Subject: RE: MacWight dilemma (Mac)

    Possible (though unlikely) solution to the MacWight (MacWrit, or
whatever) Virus:

    Anyone out ther familiar with Timbukto?  That nice little DA that
allows one user on a net to actually attach his mac to another running
on the same net.  Even take over the other mac if the other person
does not know what is happening.  That way it is possible to have
something change right before your eyes if you are on a net, running
Timbukto and have someone else (who is probably in hysterics) running
Tim on another mac on the net.  Try capturing someone's mac when he's
netTrek and just have fun with the poor boy.

                        it's possible...
                                   Alex Z... . .  .

------------------------------

Date:    Sun, 05 Nov 89 15:01:02 +0000
From:    Alan Solomon <[e-mail]>
Subject: Details of Ogre, Dark Avenger, etc. (PC)

There has been a number of people recently calling for information
about some of the newer viruses, like Ogre, and Dark Avenger.  What
follows are excerpts from the manual of a commercial product;  it's OK
for me to post this, as I wrote it and have the copyright!  I shan't
mention the name of the product, but I must apologise that the pages
of the manual do refer to various components of the product.  Where it
refers to Findvirus, please take this as meaning any virus scanning
program that knows about the virus in question;  when it refers to
Peeka, please take this as meaning any disk sector editor.  The
paragraph numbers are the chapter numbers in the manual.

I've taken the liberty of calling Ross Greenberg's discovery Fumble
instead of Typo, as there is already a Typo in the literature, and we
don't want two viruses with the same name.  Sorry, Ross.

If anyone finds any errors or significant omissions in these
descriptions, please respond via email or fax to me directly.

Finally, could I please lay one myth to rest.  Datacrime (called
Columbus day in the US) does the low level format on October 13th and
every day thereafter until December 31st.  It does this in versions
1168, 1280 (infective lengths) and Datacrime II.  It does NOT do
anything on October 12th, and Datacrime II does NOT go off on Jan 1 to
Oct 12th.  Datacrime II refrains from the format on Mondays.  The
whole October 12th thing was caused by a misunderstanding about dates,
picked up by the media and turned into a factoid.
The other important thing about Datacrime, is that it is extremely
uncommon indeed. We have had no (zero, nil) cases in the UK, and I
know of only two cases in Holland.  Does anyone know of any
*confirmed*, definite, sightings? Apart from Fridrik's self inflicted
accident, of course :-)

Dr Alan Solomon                Day voice:     [phone]
S&S Anti Virus Group           Eve voice:     [phone]
Water Meadow                   Fax:           [phone]
Germain Street,                BBS:           [phone]
Chesham,                       Fido node:     254/29
Bucks, HP5 1LP                 Usenet:        [e-mail]
England                        Gold:          83:JNL246
                               CIX, CONNECT   drsolly

[Ed. Because of the length of the excerpts, I've sent them to the
comp.virus documentation archive sites.  Access information will be
posted shortly.]

------------------------------

Date:    Thu, 09 Nov 89 13:51:40 -0600
From:    [e-mail] (Vince Laurent - work id)
Subject: Another attack?!? (PC)

We have encountered something that appears to be a virus of some sort.
The symptoms are :
     1. When an EXE file is run that is 'infected' the screen gets lines
        and garbage that looks like 'snow' (TV term there...)
     2. After a few runs it changes the file length to 0.
     3. When the disk is checked using some utilites there are numerous
        'bad sectors' scattered on the disk.
Side Note: The color of the 'snow' is the same as the last application that
           ran (ie when Norton Editor is run with a green screen - there is
           green snow, white screen editing makes white snow, etc...)

I have not been able to 'capture' this virus to get a look at the code. I
know of 3 cases so far, some of my coworkers have run across it too.

Any ideas on what it might be?

                        ---------------------------------------------
                        | Vincent J. Laurent                        |
                        | Help Desk                                 |
                        | Computing Affairs                         |
                        | Southern Illinois University - Carbondale |
                        | CA6692@SIUCVMB                            |
                        ---------------------------------------------
p.s. please! no comments about yellow snow...

------------------------------

Date:    Thu, 09 Nov 89 15:17:25 -0400
From:    "Joel B. Levin" <[e-mail]>
Subject: Re: Sophisticated Viruses?

>I don't agree with you on any of these points, Terry. Say, on the
>Macintosh all calls to ROM are done through trap vectors in RAM. These
>trap vectors are patched by the system file (to fix bugs), by some
>programs and by all anti-virus tools. However, it doesn't take a
>genius to figure out that one could restore the trap vector to it's
>original value and thereby bypassing the "safe" system.  . . .
> . . . A patch like this wouldn't occupy much space and is quite
>simple to write.

Except that when system patches or INIT patches or program patches to
the traps were removed by the virus (and how would the virus decide what
value to restore them to?--this is different for each ROM and system
release version) the user would certainly be likely to notice the
resultant changed program behavior -- or system crashes.

    /JBL

------------------------------

Date:    Thu, 09 Nov 89 14:51:40 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Checksum programs; Hardware protection

  Concerning checksum programs, Paul Kerchen writes:
>           where does one store these checksums and their keys?  If
>they are stored on disk, they are vulnerable to attack just like
>programs.  That is, a virus could infect the program and then update
>its checksum, since the key must be somewhere on disk as well (unless
>the user enters it every time they compute a checksum--yecch!) and one
>must assume that the checksum algorithm is known.  Or,
>more simply, a virus could simply wipe out all the checksums,
>leaving the user to decide which files were infected.  Storing the
>'sums off line would insure security, but at what cost?  Checking
>and updating the 'sums with any frequency would become tedious at best.

  First, let's rule out the possibility of wiping out the checksums.
To be successful, a viral attack (as opposed to a Trojan Horse attack)
must not be obvious.  Such an action would immediately be noticed.
That leaves us with the more subtle action of altering checksums.
  Now there are two types of CSPs (checksum programs), sometimes
called "dynamic" and "static", and most of Paul's remarks seem to be
based on the assumption that we are using the dynamic type.  Dynamic
CSPs are resident programs which checksum each program which is execu-
ted just before its execution.  A well-known example is the checksum
feature of FluShot+.  Static CSPs are non-resident programs which
checksum a list of many files on demand, usually at boot time by vir-
tue of being placed in the AUTOEXEC.BAT file.  An example is Sentry.
  Now the dangers described above by Paul are no problem for static-
type CSPs.  In this case one can keep the CSP, along with the CSB
(checksum base) and key (generating polynomial in the case of a CRC),
on a write-protected, non-infected bootable diskette, and execute the
CSP from that diskette after cold-booting from it.  Since the CSP is
static, this need be done only once per boot, and the additional in-
convenience relative to doing this from the hard disk will be very
slight.  (In fact, there are even utilities which allow you to specify
that the program is to be executed only once a day, once a week, etc.
even though the command is in AUTOEXEC.BAT.)
  But suppose one wants to execute the program from the hard disk any-
way.  We can still foil the checksum forger by simply requiring the
user to supply the key interactively.  "Yecch!", says Paul, but he is
probably thinking of dynamic checksumming.  Again, if one uses static
checksumming, the key need be supplied only once per boot at the most.
  Now let's suppose we're using a dynamic-type CSP and prefer the con-
venience of doing everything from the hard disk.  Would this really
make the checksum and keys vulnerable, as Paul claims?  Even if it's
true that *theoretically* a virus could find the CSB and key and then
alter the former, in practice that seems to me rather unlikely for a
variety of reasons:  First, if the CSB is stored under a name that is
not fixed, how would the virus find it?  If it does it by searching
all files on the hard disk looking for a certain type of content, then
infecting some file and computing its new checksum from the key which
it has discovered and updating the CSB, that would take a lot of time.
One must remember that any modification in a program which causes it
to take much more time than usual is likely to be noticed by the user,
causing him to suspect a virus.
  Secondly, forging checksums would make a lot more sense if there
were a single CSP which was used by a majority of the users of a
given type of computer.  But what good does it do to write a program
to forge checksums used by a particular type of CSP when it is use-
less on the overwhelming majority of computers?  Unless the virus
creator is satisfied with attacking a very limited environment, such
as a student lab, in which all computers use the same CSP, checksum
forging hardly seems worthwhile.
  This is not to say that there are no dangers to CSPs.  But checksum
forging is not the main one.  On most systems there are CSP-fooling
techniques which are not only much faster and independent of the par-
ticular CSP, but also easier to write.
  To give a PC example, suppose the hard disk and RAM are infected by
a boot-sector virus which hooks Int 13h in such a way that any attempt
to read the boot sector results in reading the sector in which the
virus has stored the original boot sector (i.e. it works like the
Brain virus except that it infects the hard disk also).  If the com-
puter is booted from the hard disk, the CSP will be activated only
after the virus has installed itself in RAM, hence checksumming the
boot sector will not reveal that the boot sector has been modified.
  This particular trick can be overcome by booting from a clean disk-
ette before activating the CSP.  But on the PC, at least, there are
several other ways of fooling a naively designed CSP which cannot be
overcome in this way.

  Chuck Kichler says things similar to what Paul says above, except
that he suggests looking in the program (the CSP) instead of in the
CSB.  The answers are similar.  However, he also suggests using a
hardware device.  This is not a new idea, and there is at least one
commercial implementation of this for PCs, called Disk Defender, con-
sisting of a card placed between the disk drive and the controller.
It comes with software for dividing the hard disk into two logical
drives, one of which is left unprotected for necessary writing, while
the other is completely write protected, except when it is necessary
to transfer files to it.  I agree that this is one of the best types
of anti-viral protection.  But even if we ignore the tedious installa-
tion required (if the disk is not initially empty) and the relatively
high price ($240, last I heard), one should not assume that it neces-
sarily provides absolute protection; it may still be possible for a
virus to infect the normally protected drive during those periods when
the protection is removed in order to transfer new files to it.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

Date:    Thu, 09 Nov 89 14:56:05 -0500
From:    "Mark S. Zinzow" <[e-mail]>
Subject: Ping Pong virus (PC) at UIUC

This is a slightly edited copy of our local warning.

Today (Thursday, November 9, 1989) the Ping Pong B virus was found
on an XT in Newmark hall here at the University of Illinois at
Urbana-Champaign.  This is the third virus to infect IBM PC's here.
The previous PC viruses were Brain and Jerusalem.

This virus is a boot sector infector and also goes by the names
Bouncing Ball, Italian, VERA CRUZ, and VERA CRUZ B.

Please use scanv48.arc (anonymous ftp'able from uxe.cso.uiuc.edu
in the directory pc/virus) to search systems for infection, and
unvir6.arc (from the same place) to remove the virus from infected
systems.  VIRUSCAN, the name for the package of programs in
scanv48.arc, is a shareware product.  Just this week CSO has
purchased a site license for the U. of I. so you may ignore the
request for a $25 registration if you are using this software here.

SCAN.EXE (in scanv48.arc) will report two versions of Ping Pong when
it is found.  This is a bug, the B version also triggers the message
for the non-B version.  So far, we think we only have one version
of this virus floating around.

The program IMMUNE by Yuval Ratavy in unvir6.arc will make your
system immune to the Ping Pong, Jerusalem, and several other
viruses.

Please call me (244-1289 or email [e-mail]) if you
find a copy of PING PONG as I'm trying to figure out the extent and
locations where this virus has spread.

In the local versions of this announcement, excerpts from the following
VIRUS-L Digests were included:

VIRUS-L Digest            Wednesday, 18 Jan 1989        Volume 2 : Issue 18
 Subject:     Re: The Ping-Pong virus (PC)

VIRUS-L Digest             Thursday, 9 Mar 1989         Volume 2 : Issue 61
Subject:     Re: Bouncing ball virus (PC)

VIRUS-L Digest              Friday, 10 Mar 1989         Volume 2 : Issue 62
Subject:  bouncing ball virus (PC)

VIRUS-L Digest            Wednesday, 10 May 1989       Volume 2 : Issue 112
Subject: Yet more on SYS (PC)

VIRUS-L Digest              Friday, 12 May 1989        Volume 2 : Issue 114
Subject : 1 byte can save us from the Ping Pong virus (PC)

- -------Electronic Mail---------------U.S. Mail---
ARPA: [e-mail]         Mark S. Zinzow, Research Programmer
BITNET: [e-mail]         University of Illinois at Urbana-Champaign
CSNET: [e-mail]      Computing Services Office
 "Oh drat these computers, they are  150 Digital Computer Laboratory
   so naughty and complex I could    1304 West Springfield Ave.
  just pinch them!"  Marvin Martian  Urbana, IL 61801-2987
USENET/uucp: {uunet,convex,att}!uiucuxc!uiucuxe!zinzow
Phone: [phone]  Office: CSOB 110 \markz%uiucvmd

------------------------------

Date:    09 Nov 89 23:09:50 +0000
From:    [e-mail] (Paul Kerchen)
Subject: Re: virus problem undecidability

[e-mail] (Peter W. Day) writes:
>A note to the virus-l digest of 6-Nov-89 said that "the virus problem (at
>least detection anyway) is undecidable."  Does anyone know if there are
>any papers where this result is proved? Or where the problem is
>shown to not be NP complete? Or even where the problem is stated
>precisely?

(Sorry about the mail loop, Peter)

I base my arguments upon Fred Cohen's paper "Computer Viruses: Theory
and Experiments," which can be found in _Computer Security: A Global
Challenge_ ( a collection of security-related papers).  In this paper,
Cohen talks about the undecidability of detecting viruses in a program
and proves why this is the case (although, purists wouldn't call it a
proof).

Paul Kerchen                            | [e-mail]

[Ed. The cited Cohen paper was also published in the _Computers and
Security_ journal (though I don't have an issue number), as well as
directly from Dr. Cohen.]

------------------------------

Date:    Thu, 09 Nov 89 20:46:04 -0600
From:    [e-mail] (Jim Wright)
Subject: New IBMPC anti-virals

More anti-virals.  It's getting hard to keep up these days...  :-)

In brief:

alert14g.zip    Checks files for changes, use in AUTOEXEC
ckot094.zip     *** Serious bugs, do not use ***
datacure.arc    Removes DataCrime virus and prevents damage
m-dav.zip       Removes Dark Avenger virus
netscan.zip     Network compatible program to scan for viruses
scanrs48.arc    Resident program to scan for viruses
scanv48.arc     Scans files, directories, drives for viruses
validat3.zip    Use this to check downloads for integrity


alert14g.zip
        Update to the alert13u program in the archives.  Add to your
        AUTOEXEC and it will check the files you specify to make sure
        they have not changed.  Free to government, shareware otherwise.
ckot094.zip
        CHECKOUT, a shell program to simplify use of scanv when scanning
        multiple archives.  Shareware.  WARNING!!!!  This program has a
        tendency to delete any file it can find.  This is a rather nasty
        bug.  I would recommend you not use any version of this program
        until an update is released and independently tested.  It should
        already be removed from the anti-viral archives.
datacure.arc
        A working version of the DataCure program to replace the
        apparently mangled version I got earlier.  Includes a program
        to cure infected files and a program to prevent the DataCrime
        virus from zapping your disk.  Shareware.
m-dav.zip
        A program to remove the Dark Avenger virus.  Shareware.
netscan.zip
        Network compatible program to scan disks for viruses.  An
        update to the previous archive of the same name.  This program
        is not quite shareware, in that a site license is required
        for continued use rather than a simple registration.
scanrs48.arc
        Resident program to scan programs for viruses before execution.
        Update replaces previous version.  Shareware.  Includes the
        VALIDATE program.
scanv48.arc
        Program to scan files, directories and drives for viruses.
        Update replaces previous version.  Shareware.  Includes the
        VALIDATE program.
validat3.zip
        Checksum program to use for validating downloads.  Run this on
        a file, note the numbers it gives, and compare this with
        the numbers provided by a trusted source.  What is a trusted
        source?  That is being worked out. :-)

Jim

------------------------------

Date:    10 Nov 89 07:38:05 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: future viruses on a PC Pull plug before cleaning

Sorry again turning off power will stop the current execution of the
virus...  but... unless you are perfect in your safe computing habits
and your tools are up to snuff and you give your harddisk an
engineering prep as you power up and ALL your software is clean.. you
can still be hit upon power up...  following post you invok int19 to
read the boot tracks in loc 7c00 it is at this point you are first
vunerable...and not under control of ANY antiviral tool I have heard
about...(VIRUS_PROOF pc designs not withstanding... even cd-rom has
been infected during the production of shareware libaraies...)  but
you wont incurr damage to your data while power is off but neither can
you get to it either...I am not saying the problem is unsolvable nor
hard to deal with just realize the power off switch is no REAL
protection some time or another you will eventually power up...
    cheers
    kelly

------------------------------

Date:    10 Nov 89 07:53:56 +0000
From:    wugate!smu.edu![e-mail] (Bob Mazanec)
Subject: In Search Of Virus Info

I am trying to find any and all information available on computer (UNIX
& others) viruses for a report in an ethics class (gee, i bet this
stuff might even be useful to me in running my little VAX, huh?).

Please E-MAIL me any information you might have (or even just references to
magazines/books that might have same) on
    known viruses
        what/where/when/how/etc.
    psychology of virus writers
    immunology
        what can/has been done
    bug exploitation/fixing
    etc.

MANY Thanks in advance!!
Robert L. Mazanec @ Southern Methodist University
{attctc, convex, texsun}!smu!mazanec == [e-mail]

DISCLAIMER: You think they TAUGHT me this stuff??

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 13 Nov 1989    Volume 2 : Issue 239

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

New Virus (PC)
Interferon & The Vision Fund (Mac)
"The Cuckoo's Egg," Cliff Stoll, Doubleday, New York ($18.95),
Virus trivia (PC)
Re: MacWight? (Mac)
Re: Where are the Sophisticated Viruses? (PC)
Previous Incorrect Attribution
New Virus (PC)
Re: Identify Ashar Virus (PC)

---------------------------------------------------------------------------

Date:    Fri, 10 Nov 89 09:32:38 -0800
From:    portal!cup.portal.com![e-mail]
Subject: New Virus (PC)

     A new COM infector was submitted to the HomeBase board this
evening by Jean Luz of Lisbon, Portugal.  The virus is in many
respects similar to the Vienna virus - the size increase is 648 bytes,
and instead of overwriting every eigth file (on the average) with the
re-boot sequence, it overwrites with the characters "AIDS", thus
crippling those applications.  This virus shoulkd not be confused with
the original AIDS virus (very dissimilar).  Asside from the mentioned
similarities with Vienna, the virus appears to be written from
scratch.  The 648 length seems to be a chance result.  No effects of
the virus have been observed other than the above mentioned.  The
virus has been in Portugal at least two months according to the
submitter.  Alan

P.S.  The following presumably straight-faced request was posted on
HomeBase by John McAfee.  Thought it might be of interest to Virus-L
readers:

To: All Users
From: John McAfee
Subject: Reported Possible Virus

    I received an unusual call from a Mr. Fred Hankel of Fargo, North
Dakota this morning.  Mr. Hankel was highly agitated and after hearing his
long and involved story, I was moved to pass on this condensed summary to
all who might be interested:  Mr. Hankel reports, and I have no grounds for
doubting, that a computer virus invaded his system from a bingo game he
purchased in mid-October.  The virus activated at 11:00 A.M yesterday and
promply melted his power supply and mother board.  As he reached for the
power switch to turn off the machine, the virus blasted a perfectly circular
hole in the front panel of his AT clone and left a three foot oval scorch
mark on the back wall of his den.  I had not heard of this virus before
and felt that an alert might be in order.  Anyone experiencing similar
symptoms should contact us immediately.
Thank you.

[Ed. Sounds (to me) like paranoia strikes deep.  I trust that everyone
will have the good sense to take this report with a large grain of
salt...]

------------------------------

Date:    Fri, 10 Nov 89 22:17:27 +0000
From:    biar![e-mail] (Robert J Woodhead)
Subject: Interferon & The Vision Fund (Mac)

On behalf of the Vision Fund, I would like to thank everyone who has sent
in a Shareware donation for use of the Interferon program.  We have
collected a substantial amount of money that has gone to good use.

Now I have a request:  Please don't send in any more money!  Interferon
is now an obsolete program; Shareware programs like Disinfectant and
commercial programs like (plug, I wrote it) Virex are faster and better.
In addition, I've been told by my accountants that the informal structure
of the Vision Fund can cause me some tax problems if too much more money
comes in.

Therefore, I declare both Interferon and MandelColor (another Vision Fund
program) to be Freeware.  After a certain date, any cheques received made
out to the Vision Fund will be returned.  Any cash sent in, or cheques made
out to Yours Truly, will be spent on wooing women.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!


------------------------------

Date:    Sat, 11 Nov 89 07:41:00 -0500
From:    [e-mail]
Subject: "The Cuckoo's Egg," Cliff Stoll, Doubleday, New York ($18.95),

>(In my personal opinion, by
>the way, "The Cuckoo's Egg" should be considered required reading by
>anyone who runs, or is interested in, computers - *highly*
>recommended.) -- Ken Van Wyk

As much as I like Cliff Stoll, I still hate to be forced to sell his
book.  Nonetheless, I am force to agree with Ken on this: the book is
required reading.  It is so much so, that I do not even harbor any
qualms about saying so on the network.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Sat, 11 Nov 89 12:34:24 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Virus trivia (PC)

Just a few random bits of information....

        * A diskette infected with the Ohio virus will be immune to
          infection by the Brain and Den Zuk viruses, since it contains
          the signature of those two viruses.

        * The Vacsina virus can only properly infect a .COM file, so
          when it infects a .EXE file it will do so in two steps, first
          change it into a .COM file by overwriting the 4D 5A signature
          with a JMP instruction and placing a 132 byte loader program
          at the end of the file. The next time this program gets infected
          it will be infected just like any other .COM file.

        * Almost all .EXE infecting viruses place the virus code at the end
          of the infected file. One virus, sURIV 2.0 does not. It will insert
          itself just after the header of the program it infects.

And one question.. What language is "Den Zuk" ? I thought it was Dutch for
"The search", but I have been told that it is not.

- -frisk

------------------------------

Date:    10 Nov 89 16:46:36 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: MacWight? (Mac)

[e-mail] (Joe McMahon) writes:
>You may (or may not :-) remember the discussions we had here on the
>list about this. As far as I remember, there was never a specific
>demonstration that there was a virus involved. That doesn't mean that
>there wasn't; it just means that there were never quite enough facts
>presented to make a case either way. I'd leave it off for now, or
>mention it as a "rumored sighting" or whetever. Safest not to mention
>it, especially since it was never pinned down and analyzed.
>
> --- Joe M.

I agree whole-heartedly!  Please *do*not* mention this alleged virus -
the paranoia the initial reports of this alleged virus have given way
to is damage enough.  There is still *no* evidence that this virus
ever existed.

Since my initial postings on this subject, I have received a couple of
files that, it was thought, might have been infected by this alleged
virus.  I found no indication of any virus (or anything at all out of
the ordinary) in those files.

Once again, there is still *no* evidence that this virus ever existed.
If new evidence surfaces, this disucssion can continue, but at the
moment there's no evidence and, consequently, nothing to discuss.  The
end.

"The onus of proof is on he who asserts the positive."

Cheers,
- ----Chris
- [e-mail]

------------------------------

Date:    Sat, 11 Nov 89 19:52:07 +0000
From:    [e-mail] (jim frost)
Subject: Re: Where are the Sophisticated Viruses? (PC)

[e-mail] (Fridrik Skulason) writes:
>jim frost writes:
>>Given the limited resources of PC environments, it's
>>unlikely that you'll get a very sophisticated virus.

>I must disagree. In the PC environment it is not a question of limited
>resources, but rather the fact that any user process has full access to
>ALL resources and can even directly manipulate the hardware if required.
>So, my opinion is that it is even easier to write a sophisticated virus on
>the PC than in most other environments.

No, it's harder.  Most of the items which I consider sophisticated
require fairly fancy programming which requires code space, data
space, and CPU time, each of which is at a premium in most PCs.  A
really sophisticated virus, one targeted for UNIX, for instance, could
easily approach or exceed a megabyte in size.  You just can't do that
on most PCs, and users would notice even if you could.

On the other hand you don't need to.  MS-DOS systems are so trivial
that it's difficult to build a good virus detector and there are no
inherent security systems.  Viruses don't need to be sophisticated.

>Finally, I want to add one "feature" to the description of a sophisticated
>virus:

>"Bypass protection programs and jump directly to the hardware, DOS or
>BIOS routines."

I didn't add that because that's not usually one of the "survival"
traits, but rather is used in propagation and/or infection.  I have a
fairly lengthy document on the kinds of things a real sophisticated
virus might do in each stage (what I showed before was a subset of
this document).  I consider the document sensitive so I am wary of
posting it.

jim frost
[e-mail]

------------------------------

Date:    11 Nov 89 21:56:43 +0000
From:    [e-mail] (Kelly Goen)
Subject: Previous Incorrect Attribution

Hi all,
      Well it seems I have been guilty of incorrect attribution
of an article I forwarded for Aryeh Goretsky... The forward was NOT
officially from the CVIA nor does it represent an official opinion
of th CVIA. The forward was from Aryeh Goretsky who was not acting
in any official capacity for the CVIA. Here I am redfaced indeed!!
my fault only in the incorrect attribution...
           cheers
           kelly


------------------------------

Date:    Sat, 11 Nov 89 14:39:50 -0800
From:    portal!cup.portal.com![e-mail]
Subject: New Virus (PC)

    Yet another virus has been reported and sampled in the Seattle
area.  The virus is a COM, EXE and Overlay infector that increases the
size of infected files by 1644 bytes.  It activates on Sundays and
displays the message: "Today is Sunday!  Why do you work so hard?  All
work and no play make you a dull boy."  File allocation table damage
has been reported in two instances, although we could not dupliacte
the FAT problem on our test systems.
    McAfee is planning to put SCAN49 out on Tuesday.  49 will detect
this Sunday virus, the Lisbon Virus and Yuval Tal's Do Nothing virus
(He sounds pretty haggard over the phone and begins to snarl if the
words "new virus" are mentioned).
Alan

------------------------------

Date:    13 Nov 89 03:40:48 +0000
From:    munnari!stcns3.stc.oz.AU![e-mail] (Dave Horsfall)
Subject: Re: Identify Ashar Virus (PC)

It has been pointed out to me (hello Kelly!) that I may have been less
than gracious in my response to the report of "ld viruses found."
Certainly no offence was meant to John McAfee, and I hope none was
taken.

However, actual bug details aside, the point I was making that the
user of a virus-detector has to have absolute trust in it, and any
errant behaviour by the program can only weaken that trust, no matter
who the author is.  Certainly, a failure to correctly report the
number of viruses found would seem to imply a lack of testing.

Virus detectors must not only be above reproach, they must be SEEN to
be above reproach.

Anyone here read comp.risks/RISKS-L ?

- --
Dave Horsfall (VK2KFU),  Alcatel STC Australia,  [e-mail]
[e-mail],  ...munnari!stcns3.stc.oz.AU!dave

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 16 Nov 1989    Volume 2 : Issue 240

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Sophisticated viruses
Ohio vs. Den Zuk (PC)
VACSINA infects more than EXE and COM files (PC)
Re: Pull plug before cleaning
Macintosh Virus List
Need software to detect PC virus (PC)
Another Virus? (PC)
Undecidability of virus detection
Virus removal programs for use on MAC 128K
Another virus... Marijuana virus (PC)
Virus eliminators above reproach.
Sunday virus (PC)
Lisbon virus (PC)
Ralf Burger's book

---------------------------------------------------------------------------

Date:    Mon, 13 Nov 89 12:12:46 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Sophisticated viruses

jim frost writes:
> Fridrik Skulason writes:
> >jim frost writes:
> >>Given the limited resources of PC environments, it's
> >>unlikely that you'll get a very sophisticated virus.
>
> >I must disagree.
>
> No, it's harder.

The disagreement results from our different understanding of the words
"very sophisticated virus." I understood them in a relative sense,
meaning that a "very sophisticated virus" in the PC environment does
not have to be nearly as complicated or large as a "very sophisticated
virus" in the UNIX environment, and therefore much easier to write.
So, we really do not disagree regarding the fact that

> MS-DOS systems are so trivial that it's difficult to build a good virus
> detector and there are no inherent security systems.  Viruses don't need to
> be sophisticated.

> >"Bypass protection programs and jump directly to the hardware, DOS or
> >BIOS routines."
>
> I didn't add that because that's not usually one of the "survival"
> traits, but rather is used in propagation and/or infection.

No, because a part of the "survival" is to avoid detection. Many
protection program simply hook interrupts, and any virus that bypasses
the interrupt table has a good chance of avoiding them altogether.

- -frisk

------------------------------

Date:    Mon, 13 Nov 89 11:54:52 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Ohio vs. Den Zuk (PC)

It is obvious that the "Den Zuk" and "Ohio" viruses are somehow related,
but the nature of their relationship has not been determined yet. "Ohio"
was reported later, but there is a possibility that it is older than
"Den Zuk".

I said in an earlier note that a diskette infected with Ohio would be
immune to infections by Brain and Den Zuk. This is not entirely
correct. The diskette will be immune to infections by Brain, but when
Den Zuk finds a "Ohio"-infected diskette, it will remove the virus and
put a copy of itself there instead.

As I have mentioned before, the "Ohio" virus contains the signature of
the "Den Zuk", but it also contains some interesting text strings:

                      V  I  R  U  S
                           b y
                       The Hackers
                       Y C 1 E R P
                      D E N Z U K O
                      Bandung 40254
                        Indonesia

                (C) 1988, The Hackers Team....

Remember that Den Zuk puts the volume label Y.C.1.E.R.P on
Brain-infected diskettes, when it removes the infection.

(And yes, by the way, both viruses only infect diskettes, not hard
disks).

The "Den Zuk" virus contains the following text strings:

                        Welcome to the
                           C l u b
                        --The HackerS--
                            Hackin'
                         All The Time

                         The HackerS

On a more technical level, the viruses are very close. Both store the main
part of the virus on track 40, starting at sector 33. (Remember that normal
360K diskettes have only tracks numbered 0..39 and sectors 1..9) They also
hook INT 9, take action when Ctrl-Alt-Del is pressed and in both cases
a true reboot can be produced by pressing Ctrl-Alt-F5.

And of course - the "Ohio" virus has the same "bug" as "Den Zuk" - it can
not infect other types of diskettes than 360K properly.

A part of the "Den Zuk" virus may explain the relationship. The following
code fragment is used to determine if a diskette should be infected or not.

    CMP    [SIGN1],537CH        ; Is current diskette infected
                    ; with this version of Den Zuk ?
    JE    BP0300            ; Yes, do not infect.
    CMP    [SIGN2],0FAFAH        ; No, but is it infected with
                    ; (probably) an older version ?
    JE    BP0280            ; Yes, update the virus.
    CMP    [SIGN3],1234H        ; No, but is it infected with Brain ?
    JNE    BP0290            ; Yes, remove it.
                    ; No, just infect.

"Ohio" contains the signature FAFA in the specified location.

My theory is that the "Ohio" virus is the missing "older version" of
"Den Zuk", that it was written by the same authors as "Den Zuk", but
earlier. The authors of Ohio released it to fight the Brain virus, but
since it contained a number of bugs, the "Den Zuk" virus was later
released to track it down.

One final question. I understand that a variant of Dutch is spoken in
some parts of Indonesia - do the words "Den Zuk" mean anything over
there ?

- -frisk

------------------------------

Date:    Mon, 13 Nov 89 13:41:09 -0500
From:    Christoph Fischer <[e-mail]>
Subject: VACSINA infects more than EXE and COM files (PC)

Hi,
VACSINA infects any file that is loaded and executed via the INT 21H(4BH)
function. So additionally to COM and EXE files other files like OVL or
APP are infected as long as they start with E9H (jump) or 'MZ' (EXE header).
We have written a program that detects VACSINA and removes it from those
files. Also we have an immuniser that prevents VACSINA from installing its
memory resident copy.

Christoph and Torsten

*****************************************************************
* Torsten Boerstler and Christoph Fischer and Rainer Stober     *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone] or 2067   *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET    *
*****************************************************************

------------------------------

Date:    13 Nov 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: future viruses on a PC; Pull plug before cleaning

> Sorry again turning off power will stop the current execution of the
> virus...  but... unless you are perfect in your safe computing habits
> and your tools are up to snuff and you give your harddisk an
> engineering prep as you power up and ALL your software is clean.. you
> can still be hit upon power up...

The usual idea is that you boot from a known-safe *diskette* when
you want to get the system into a clean state for checking.  With
enough effort, it's possible to get a diskette whose possibility
of being infected is as small as you like; if you boot from that,
you can check your hard disk without having to assume that it's
clean already (when a machine boots from a properly-prepared
diskette, as you know, no code from the hard disk is executed).
That was, I think, what was being suggested in the item
you're replying to...              DC

------------------------------

Date:    Mon, 13 Nov 89 11:35:30 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Macintosh Virus List

After much scrutinization I ahave ammended the earlier Macintosh virus list
and came up with the following.  Hope this helps.

Macintosh Viruses
- -----------------

There are about six Macintosh viruses known at present (a list
of viruses and the years in which they first appeared can be seen
in the following table).
- -----------------------------------------------------------------
Virus                         Strains       Clones
- ------                        --------      --------
MacMag(December 1987)**
Dukakis(Early 1988?)****
nVir(Early 1988)
                              nVir A(?)
                              nVir B(?)
                                            Hpat(Late 1988)
                                            AIDS(Late 1988)
                                            MEV#(March 1989)
                                            nFLU(August 1989)
Scores(Spring 1988)***
INIT 29(Late 1988)*
ANTI(Early 1989)
- -----------------------------------------------------------------
   * - also known as the Drew Virus, Brandow Virus, and the
       Peace Virus
  ** - also known as the NASA virus
 *** - also known as the San Jose Flu
**** - can only infect HYPERCARD Stacks!

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Mon, 13 Nov 89 18:11:00 -0500
From:    [e-mail]
Subject: Need software to detect PC virus (PC)

I need to find software to detect and purge viruses from DOS-PC
software.  I have seen vaccine software in magazines and catalogs
but no description of how it functions (whether it automatically
destroys the virus and the software attached, or if it can be a
bit selective).  Can any one elaborate a bit on the value of the
following vaccines or suggest software with which they are familiar.

Compugard Anti-Virus
Flu-Shot+
Flushot(1225)
Mace Vaccine
Virus Killer

Any Discussion would be helpful.  Send replies to:

[e-mail]
Doug Johnson
Computer Users Services
Norwich University
Northfield, VT 05663

------------------------------

Date:    Mon, 13 Nov 89 18:45:00 -0500
From:    IA96000 <[e-mail]>
Subject: Another Virus? (PC)

Over the weekend a file named EAGLE.EXE was uploaded to my BBS.
My system run extensive tests on ALL new files before they are
released for general use and downloading. I checked the log and
NO reports of anything you may consider improper were found after
checking the uploads.

EAGLE.EXE is said to produce a VGA animation of an EAGLE flying
in the sky. For those interested in VGA animations it would appear
to be of interest.

I ran EAGLE.EXE and all that happened is the program produced the
following line on the screen:

Kiss an Eagle Today!

Being of suspicious nature, I immediately started to check the file
using SCANV48 and other utilities. No indication of a virus was
detected or reported.

HOWEVER,running certain files after running EAGLE.EXE caused them to
grow in size. Okay, cold booted and ran SCAN and other utilities again.
Same result, no report of infection. But as soon as you run EAGLE.EXE
again, files start to get larger.

There has been NO apparent FAT TABLE damage, and no files have
suddenly disappeared. Other than files growing in size, there appears
to be nothing else happening yet!

The file EAGLE.EXE probably has been or will be uploaded to Homebase
by the time you read this message. If not, it will transfered tonight
as soon as we can get through.

NOTE:    SOURCER  reveals code similar to other viruses in existance,
but I will defer to experts and let them decide what exactly is
contained in the EAGLE.EXE file. In all likelihood this IS NOT a
new virus, just a modification on an old one, however again I will
defer to the experts!

SUSPECT FILE NAME: EAGLE.EXE
     DESCRIPTION : Supposedly a VGA animation of an EAGLE.


DISCLAIMER:

    This virus (or whatever you want to call it) HAS NOT affected
any computers or files at this University. It was discovered on a BBS
run by a student who attends this University.

------------------------------

Date:    Sat, 11 Nov 89 12:25:00 -0500
From:    [e-mail]
Subject: Undecidability of virus detection

In VIRUS-L Digest   Thursday,  9 Nov 1989    Volume 2 : Issue 237,
Peter Day writes

    `A note to the virus-l digest of 6-Nov-89 said that "the virus
    problem (at least detection anyway) is undecidable."  Does
    anyone know if there are any papers where this result is
    proved? Or where the problem is shown to not be NP complete?
    Or even where the problem is stated precisely?'

There are two parts to this question.  First, precisely what is a
virus and second, how hard is it computationally to determine whether
a candidate program contains a virus.  Precise specification of
viruses is an open-ended discussion, but almost any reasonable
definition will lead to the same conclusion.  For the sake of this
discussion, let's agree that a virus modifies something it shouldn't.
(A program which makes undesired modifications does not necessarily
contain a virus, but all viruses make undesired modifications.)

Determining whether a program makes undesired modifications is
equivalent to determining whether it ever computes a particular
result, which is equivalent to the halting problem.  Hence
determination of the presence of a virus is undecidable.  This is not
a formal proof, of course, but a student in a first course in formal
systems ought to be able to supply the necessary framework and details.


Undecidability is unfortunate, but not the end of the world.
Approximate virus detectors are entirely feasible.  The undecidability
result simply guarantees that any detector must err sometimes.  It may
err by failing to find some viruses, or it may err by falsely finding
viruses where they aren't.  (Or it can hang up in a loop and never
terminate.)  Most virus-finding programs in use today err on the side
of missing some viruses.  Maria Pozzo and I are conducting research
along the alternate line.  (See our paper in the 1989 IEEE Symposium
on Security and Privacy, Oakland, CA, if you want further details.)

Steve Crocker

------------------------------

Date:    14 Nov 89 07:03:23 +0000
From:    [e-mail] (jeff kulp x2174)
Subject: Virus removal programs for use on MAC 128K


   I have a friend with a MAC 128K that got a bad case of nVIR A
from another MAC.  His MAC is running system 4.1 and has a 20MEG harddisk.
Are there any Virus removal programs that will run on this machine.  The
programs that I have found (Disinfectant, VirusRx, Interferon, etc) all
require at least 220K of RAM.  Any help would be appreciated.



------------------------------

Date: 14 Nov 89 17:07:04 GMT
From: [e-mail] (Bill Weston)
Subject: Another virus... Marijuana virus (PC)

 A program called XTREE.EXE is suspect in spreading a very annoying
virus.  A friend used this program and was consequently infected.  The
first time he ran the program the computer simply locked up.  He then
re-booted and got the following message - YOUR PC IS STONED !
LEGALIZE MARIJUANA!

 I have not been able to examine the infected disks personally so the
information that I have is just what I have been told.  The Virus
causes many READ/WRITE errors and does spread to floppies.  It has
apparently infected COMMAND.COM and the BOOT area of the disk,

 The real nasty part is that the chap who has been hit is pretty new
to MS-DOS machines.  In fact he barely has the system set up at all.

 If anyone has had experience with this VIRUS I would thank you for any
advise.

Bill Weston == ...!usceast!uscacm!12!Bill.Weston

------------------------------

Date:    Tue, 14 Nov 89 15:06:28 -0600
From:    MITCH COTTRELL <[e-mail]>
Subject: Virus eliminators above reproach.

I AGREE....  All virus elimination programs MUST be seen and BE above
reproach this includes software from public sources.  I have already
see a "elimination" program for Juruselem that says all is fine, But
the scan program still says t hat it is infected.  Which is right.
Both came from the same source.  (McAffee Associates)

I am not perfect in my software, But two programs that test for the
same thing would be assumed to give the same result.  If they don't,
one is not working ri ght.  Can you afford to gamble and GUESS which
one is wrong??? It may cost more than you think........
Acknowledge-To: <C2852@UMRVMB>

------------------------------

Date:    Tue, 14 Nov 89 22:44:50 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Sunday virus (PC)

The "Sunday" virus reported here recently seems to be little more than a
variant of the Israeli/Jerusalem virus.

There are some differences - the length of Israeli/Jerusalem is 1808 bytes,
but "Sunday" is only 1631 bytes long. Jerusalem defines INT 21 subfunction
E0 to check if it is installed, but Sunday uses subfunction FF.

It is, however, so similar to the original virus, that the only modification
I had to make to my virus removal program to cover "Sunday" was to change
one line in the "remove_israeli_or_fu_manchu" procedure:

        if (virlen == 1808)
to
        if (virlen == 1808 || virlen == 1631)

No other changes needed, not even new signature strings.

This means that we only have 39 different viruses to worry about, not 40. :-)

Anyhow - it is always getting harder and harder to determine what is a new
virus and what is just a variant. Viruses Like "Ghost" and "Mix1" that
combine parts of two viruses are not making that job easier...!

- -frisk

------------------------------

Date:    Tue, 14 Nov 89 23:55:44 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Lisbon virus (PC)

The "Lisbon" virus reported recently is nothing but a variant of the
Vienna virus. The major difference is that the virus seems to have been
created from the disassembly in Ralf Burger's book "Computer Viruses..."
and assembled using a different assembler than the one used to create the
original virus.

The "Lisbon" virus contains the patches added in the book to make the
virus a little less harmful than the original, just like the "Ghost"
virus I reported recently.

The reason I say that the virus has been created using a different assembler
is that in many cases different forms of the same instructions are used.
It is a rather little known fact that many x86 instructions have two
different forms, in particular the XOR instructions. For example, the
"XOR AX,AX" instruction can both be represented as

        31 C0   or   33 C0

The Microsoft assembler will generate one of the forms, but DEBUG the
other one. I don't know about TASM and other assemblers, I use MASM
and DEBUG for everything :-)

Since Lisbon contains the form not used by the original virus, it was
obviously not created by patching of Vienna. Still, this small difference
was enough to confuse both the scanning programs from IBM and McAfee,
but not my own....... :-)

There are a few differences in the code, but they are trivial.

- -frisk

------------------------------

Date:    Wed, 15 Nov 89 01:02:11 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Ralf Burger's book

I spent a part of last evening reading the book "Computer Viruses, a
high-tech disease".  This book has been mentioned here several times
before, in most cases because it contains a (slightly crippled)
disassembly of the Vienna virus.

This disassembly, and other that have been (and will be) made
generally available will become a major source of problems in the
future. The reason is quite simple. It takes a GOOD assembly language
programmer at least a couple of days to write and debug an original
virus. Given a disassembly to start from, he can complete the job in a
few hours instead. A novice may spend a bit longer time creating a new
virus built on a disassembly, but it will be MUCH harder for him to
write a new virus from scratch. It takes no genius to write a virus,
only an experienced assembly language programmer, but since the
novices outnumber the experienced ones, the availability of a virus
disassembly will result in a far greater number of people being able
to write viruses with less effort.

My opinion of the book is very simple.

I can not recommend it. This is not due to the fact that it contains
listings of "real" viruses, but rather that the information in the
book is inaccurate and out of date.

Consider for example the different virus types described. They are:

        Overwriting viruses.
    Non-overwriting viruses.
    Memory-resident viruses.
    Calling viruses.
    Hardware viruses.
    Buffered viruses.
    "Live and Die" viruses.
    "Hide and Seek" viruses.

Boot sector viruses are not mentioned in this list, or anywhere else
in the book. This is of course because they only appeared in 1988, but
the book was written in 1987. Some of the virus types mentioned are
unknown and VERY unlikely to appear at all.

Some time is spent on the subject of "Randomly occurring viruses"...

    "who can say that his software cannot be turned into a virus by
     changing a single bit ?".

... and that sort of stuff.

Still, this book is l lot better than the two other books I saw here
at the university bookstore. I guess we will never get a "good" book
on viruses, since they will probably have become obsolete by the time
they appear.

But who needs a book when we have VIRUS-L and comp/virus ?  :-)

- -frisk

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 16 Nov 1989    Volume 2 : Issue 241

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Identify Ashar Virus (PC)
VACSINA contains update facility (PC)
New viruses - 867 and 648 (PC)
Any quantitative studies of computer virus epidemiology
80386 and viruses (PC & UNIX)
Known PC Virus List
Signature Programs
XTREE virus clarification... (PC)
Re: Sophisticated Viruses

---------------------------------------------------------------------------

Date:    15 Nov 89 15:59:59 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Identify Ashar Virus (PC)

Now at least I hear the case being correctly stated...  and I will say
it myself...in the Antiviral industry(sic) there has been a distinct
lack of quality control of most popular nostrums......while small bugs
may not shake up the experienced bugs do INDEED cause the less
computer literate to really wonder about running this or that vendors
product on their system...(what with tales of FAT and primary format
wiping running rampant over the net ....... VENDORS do you hear me???
dave is stating a very salient point...  I do hope someone is indeed
listening...
      cheers
      kelly
p.s. Hi dave!!
                                    Kelly Goen
                                    CSS Inc.

DISCLAIMER: I Dont represent Amdahl Corp or Onsite consulting. Any
statements ,opinions or additional data are solely my opinion and mine
alone...
Seen in alt.sex recently   "SEX is FUN, Thats why there are so many of us!!"
My Opinion: Sex between Consenting Computers leads to Social Data Diseases!

------------------------------

Date:    Tue, 14 Nov 89 21:57:05 -0500
From:    Christoph Fischer <[e-mail]>
Subject: VACSINA contains update facility (PC)

Hi,
  we just completed our virus catalog entry for the VACSINA virus and
checked with some friends. One of them: David M. Chess pointed out
that we overlooked a fact. Well it is a very important fact: VACSINA
contains an update facility.  The last 4 bytes of an infected file
contain F4 7A 05 00. The F4 7A is the VACSINA id and 05 00 is the
version number ( lo byte first ) so we have version 0005 of VACSINA.
If the virus finds anything less than 0005 it will reconstruct the
original file and then it will infect with the new version of VACSINA.
Now we understand why the author left so much space in the head of the
virus. Also the 3 byte used for the 'VACSINA-TSR is in memory' flag
contain a 05 so future versions of VACSINA will know if an older
version of VACSINA installed its TSR.
If anybody has virus infected files that show F4 7A 06 00 or higher please
post a note.
Thanks to David again!
Chris
*****************************************************************
* Torsten Boerstler and Christoph Fischer and Rainer Stober     *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone] or 2067   *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET    *
*****************************************************************

------------------------------

Date:    15 Nov 89 00:00:00 +0000
From:    David.M..Chess.CHESS@YKTVMV
Subject: New viruses - 867 and 648 (PC)

I've been looking through a couple of new PC viruses (thanks
to John M. and Fridrik S. for the samples), and thought I'd
write down a couple of things:

  - The 867-long COM-infector that only infects on even-numbered
    days and sometimes messes up one's typing has been called
    "Typo" and "Fumble" here.   To either add to or subtract
    from the confusion, I'd suggest calling it the "867" until
    a good reason not to comes along...

  - The 648-long COM-infector that Alan Roberts reported above
    is in fact Vienna-derived.   It's functionally identical
    to the Vienna, except that it overwrites the occasional
    victim with "@AIDS" instead of the Vienna's 5-byte reboot
    program.   The code has been messed with considerably; the
    author seems to have taken a sample of the Vienna, and
    asked, for every instruction, "how can I change this to
    do exactly the same thing using a different set of bytes?".
    In many places the code is identical; in others, it has
    been tightened up, or expanded with NOOPS, or tiny and
    non-functional changes in register usage have been made.
    The perpetrator was clearly interested in fooling any
    virus scanner looking for Vienna identification strings
    (to use Joe Hirst's phrase).

DC

------------------------------

Date:    16 Nov 89 00:20:32 +0000
From:    [e-mail] (Peter Zukoski)
Subject: Any quantitative studies of computer virus epidemiology out there?

Hi -
I recently received a request from Richard Dawkins (A zoology
professor at Cambridge, author of the "Blind Watchmaker" which is a
summary of Darwinian evolution, and the software which helps one
understand the power of slight mutations coupled with huge numbers of
generations.) for information about computer viruses. Following is his
request. He doesn't have access to the interNet, so please send any
responses to me, even if this prompts a discussion in this group, as I
don't normally read it and wouldn't want to miss anything pertinent.

Please mention/send any past discussion of these issues which you
might have lying about as well.

Thanks

"Do what you want -- you will anyway."
peterz

[e-mail]
Bell: 408-974-2920
Snail: Apple Computer 20525 Mariani MS/76-3C Cupertino, CA 95014

- ----------

My interest is as follows:
I want to develop a 3-way analogy between 'real' viruses, computer
viruses, andviruses of the mind.  To give the idea, I'm pasting in the
following draftproposal for a BBC television program that nearly
appeared with me as Presenter(in the end the project was shelved, but
I now want to pursue the idea further anyway).

"PROPOSAL FOR TV PROGRAM: VIRUSES OF THE MIND
Three kinds of virus.  In all three cases there is information-handling
machinery as a sitting target for parasitic self-replicating information or
'viruses'.

1. 'Real' viruses, made of DNA or RNA.  They are almost pure
information, digital information just like in computers.  They use the
reading and translating machinery provided by hosts.  Build up a picture
of host cellular machinery as a sitting target for viruses, rather like a
room full of information-handling equipment  -  xeroxes, teleprinters,
computers and so on.  The machinery is all there, vulnerable to being
exploited.  It is good at handling DNA, almost eager to handle DNA, copy
it, splice it in, decode it, build the proteins specified by the DNA code.
Viral information is like a computer program whose only real purpose is
to make copies of itself.  The protein jacket etc is just the apparatus
needed to propagate copies of the information specifying it.  Actually,
that is true of all living bodies too (the central message of The
Selfish Gene and The Extended Phenotype), but it is particularly stark
for viruses.  And the special point about viruses is that they use other organi
sms' handling machinery.  Viruses are propagated through the air
(common cold), through saliva (rabies) or other bodily fluids (AIDS).

2.  Computer viruses.  These are computer programs, written by
malicious individuals, whose essential purpose is simply to make copies of
themselves.  They may also, like 'real' viruses, have deleterious effects
upon the host.  For instance some viruses delete files at random from the
hard disc.  Once again we have the same picture of information-handling
machinery as a sitting target for parasitic information.  Computers are so
good at handling information, so powerful at doing what programs tell
them to do, that they are, in a sense, asking for trouble, asking to be the
victim of malicious, self-replicating information.  Computer viruses are
propagated by borrowed or pirated floppy discs, over e-mail networks
and so on.  Unknown before 1980s, they are now alarmingly common.
My own hard disc picked up an infection last year and it was a sinister and
eerie sensation.

3.  Mind viruses.  Human minds, too, consist of sophisticated
information-processing machinery, like computers and like the
DNA-processing machinery of cells.  Once again, because of its normal
information-processing functions, it is a sitting target for 'viruses'; it
is vulnerable to being invaded and taken over by malicious self-copying
programs.  In this case they propagate themselves via word of mouth,
print, television etc.  I think the best examples (in the sense of most
strongly resembling the other kinds of virus) are to be found in religion,
especially the kinds of fundamentalist religion that have become so
prominent in the 80s.  People actually use the word 'possessed' for the
state of being taken over by one of these influences.  I suspect that we
could actually find film of people in religious trances whose behaviour
would strongly resemble the behaviour of people mentally ill with a brain
virus.  Even if not literally the same, I think that the analogy between
the three kinds of virus could be put across convincingly, emphasizing
especially fundamentalist faith as an infectious disease of the mind.  My
own experience of getting letters from religious people (especially in
Northern Ireland) after my article in Daily Telegraph forcibly made me
think of the behaviour of computers infected by a virus.  In particular,
there is the weird phenomenon of quoting scriptural verses.  These people
had read my article, so ought to realise that I'd be unmoved by biblical
quotations.  Yet their own mind is so taken over by the 'operating system'
that is programmed to accept every word of the bible that they cannot
conceive of another mind not instantly succumbing to the same thing."

So, I'm really after any studies of the details of how computer viruses
spread that lend support to the thesis described in the above proposal.

Best wishes
Richard

- -----------------------
Thanks

------------------------------

Date:    Tue, 14 Nov 89 17:05:05 -0600
From:    Peter da Silva <[e-mail]>
Subject: 80386 and viruses (PC & UNIX)

> The isolation hardware in the I386 makes it possible to construct a
> contained execution environment...  Such an environment would be a
> useful place to test untrusted programs.

> Has anyone constructed such an environment?

Yes.

It's called "Merge 386" or "Vp/IX".

`-_-' Peter da Silva, Xenix Support. R2419 X5180
 'U`   "Have you hugged your wolf today?"

[Ed. These products, by the way, are DOS emulation boxes for i386
based UNIX and XENIX products.]

------------------------------

Date:    Wed, 15 Nov 89 12:53:57 -0800
From:    portal!cup.portal.com![e-mail]
Subject: Known PC Virus List

    The following list was put together by John McAfee.  The naming
conventions follow the ViruScan conventions.  Many thanks to David Chess
for the concept for the list's format.
            VIRUS CHARACTERISTICS LIST
                                 Copyright 1989, McAfee Associates
                                                 408 988 3832

    The following list outlines the critical characteristics of the known
IBM PC and compatible viruses.   Comments and suggestions welcomed.

==========================================================================]

Infects Fixed Disk Partition Table-------------+
Infects Fixed Disk Boot Sector---------------+ |
Infects Floppy Diskette Boot --------------+ | |
Infects Overlay Files--------------------+ | | |
Infects EXE Files----------------------+ | | | |
Infects COM files--------------------+ | | | | |
Infects COMMAND.COM----------------+ | | | | | |
Virus Remains Resident-----------+ | | | | | | |
Virus Uses Self-Encryption-----+ | | | | | | | |
                               | | | | | | | | |
                               | | | | | | | | |  Increase in
                               | | | | | | | | |   Infected
                               | | | | | | | | |   Program's
                               | | | | | | | | |     Size
                               | | | | | | | | |      |
                               | | | | | | | | |      |
Virus                          V V V V V V V V V      V        Damage
- --------------------------------------------------------------------------
Do-Nothing                     . . . x . . . . .     608       p
Sunday                         . x . x x x . . .    1636       O,P
Lisbon                         . . . x . . . . .     648       P
Typo/Fumble                    . x . x . . . . .     867       O,P
Dbase                          . x . x . . . . .    1864       D,O,P
Ghost Boot Version             . x . . . . x x .     N/A       B,O
Ghost COM Version              . . . x . . . . .    2351       B,P
New Jerusalem                  . x . x x x . . .    1808       O,P
Alabama                        . x . . x . . . .    1560       O,P,L
Yankee Doodle                  . x . x x . . . .    2885       O,P
2930                           . x . x x . . . .    2930       P
Ashar                          . x . . . . x . .     N/A       B
AIDS                           . . . x . . . . .    Overwrites Program
Disk Killer                    . x . . . . x x .     N/A       B,O,P,D,F
1536/Zero Bug                  . x . x . . . . .    1536       O,P
MIX1                           . x . . x . . . .    1618       O,P
Dark Avenger                   . x x x x x . . .    1800       O,P,L
3551/Syslock                   x . . x x . . . .    3551       P,D
VACSINA                        . x . x x x . . .    1206       O,P
Ohio                           . x . . . . x . .     N/A       B
Typo (Boot Virus)              . x . . . . x x .     N/A       O,B
Swap/Israeli Boot              . x . . . . x . .     N/A       B
1514/Datacrime II              x . . x x . . . .    1514       P,F
Icelandic II                   . x . . x . . . .     661       O,P
Pentagon                       . . . . . . x . .     N/A       B
3066/Traceback                 . x . x x . . . .    3066       P
1168/Datacrime-B               x . . x . . . . .    1168       P,F
Icelandic                      . x . . x . . . .     642       O,P
Saratoga                       . x . . x . . . .     632       O,P
405                            . . . x . . . . .    Overwrites Program
1704 Format                    x x . x . . . . .    1704       O,P,F
Fu Manchu                      . x . x x x . . .    2086       O,P
1280/Datacrime                 x . . x . . . . .    1280       P,F
1701/Cascade                   x x . x . . . . .    1701       O,P
1704/CASCADE-B                 x x . x . . . . .    1704       O,P
Stoned/Marijuana               . x . . . . x . x     N/A       O,B,L
1704/CASCADE                   x x . x . . . . .    1704       O,P
Ping Pong-B                    . x . . . . x x .     N/A       O,B
Den Zuk                        . x . . . . x . .     N/A       O,B
Ping Pong                      . x . . . . x . .     N/A       O,B
Vienna-B                       . . . x . . . . .     648       P
Lehigh                         . x x . . . . . .  Overwrites   P,F
Vienna/648                     . . . x . . . . .     648       P
Jerusalem-B                    . x . x x x . . .    1808       O,P
Yale/Alameda                   . x . . . . x . .     N/A       B
Friday 13th COM Virus          . . . x . . . . .     512       P
Jerusalem                      . x . x x x . . .    1808       O,P
SURIV03                        . x . x x x . . .               O,P
SURIV02                        . x . . x . . . .    1488       O,P
SURIV01                        . x . x . . . . .     897       O,P
Pakistani Brain                . x . . . . x . .     N/A       B

Legend:

Damage Fields -    B - Corrupts or overwrites Boot Sector
                   O - Affects system run-time operation
                   P - Corrupts program or overlay files
                   D - Corrupts data files
                   F - Formats or erases all/part of disk
                   L - Directly or indirectly corrupts file linkage

Size Increase -    The length, in bytes, by which an infected
                   program or overlay file will increase

Characteristics -  x - Yes
                   . - No

------------------------------

Date:    16 Nov 89 01:02:36 -0500
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

As a member of the American National Standards Institute's (ANSI) X9E9
working group and an active participant in standards activities
regarding computer security and authentication, I have been reading
the various comments on "Checksum" programs with a lot of interest
ever since this forum became accessible to me about 2 weeks ago. If
the comments which follow are way off-base, please forgive my newness
to the forum; perhaps these things have been discussed in the less
recent past....

I've been surprised at the lack of content regarding sophisticated
authentication algorithms. In this forum of late,I've been reading
about checksums and CRCs but I haven't heard any mention of ANSI X9.9
or ISO 8731-2, which are both extremely relevant standards. Both of
these authentication algorithms have served the international banking
community well, having been used for years to secure billions of
dollars worth of daily wire-funds transfers without a single verified
case of compromise.

Checksum programs work by attempting to "authenticate" a program or
file by calculating a number, based upon the content of the file. That
number serves as a digital "signature" reflecting the exact status of
the file at the moment when the calculation was made. Unfortunately,
authentication in hostile environments is not a trivial subject, and
has been shown to be susceptible to forgery and compromise.
Furthermore, as Paul Kerchen and Y.  Radai have recently commented,
very serious attention must be paid to exactly where the signatures
(and any component parts critical to their calculation) are stored.

In my opinion, if properly implemented, signature programs have the
potential for being much more useful than "scanners" (or any other
known anti-viral technique) in most instances, since they don't
require any foreknowledge about the viruses which may attack in the
future.

Relying on simplistic algorithms to calculate these signatures suffers
from an obvious disadvantage: Future viruses can compensate for the
way the signature is calculated, or forge signatures that appear to be
valid.  Relying on supposedly "secret, proprietary" algorithms is very
risky: the annals of cryptography are littered with the bones of
algorithms that couldn't withstand the scrutiny of dedicated
adversaries. If the history of algorithmic research can teach us
anything, it is that we shouldn't trust any cryptographic algorithms
unless they've been examined by a very large population of experts.

There is a developing science of "authentication technology" that is
revealing important facts about the kinds of algorithms that can be
relied upon to resist the scrutiny of adversaries. It's amazing how
many people are unaware of these things, and it's DANGEROUS to base
virus detection products on insecure algorithms. As this knowledge
grows and becomes more easily available to the people that write
viruses, commercial vendors of virus detection programs will be forced
to learn about this stuff the hard way.

The American Bankers Association, in cooperation with the American
National Standards Institute, (with representation from NSA, NIST,
Federal Reserve, the Vendor community, etc.) and the International
Standards Organization have endorsed standardized ways of calculating
digital signatures. There are powerful ways of using these respected,
standardized algorithms in the reliable detection of viral
contamination. It's complex and expensive to put together a practical
implementation, but once it's done it can provide a very reliable
first line of defense that won't need 49 different revisions per year
to keep up with identified threats.

By the way, for those of you that are wondering if performance will
suffer, the answer is that it need NOT suffer. Certainly,
unsophisticated implementations might turn out to be abysmally slow,
but it is quite possible and practical, with careful design and
implementation, to adapt combinations of these standards to the IBM PC
world, for example, in a way that users hardly notice. Practical
defenses based on ANSI X9.9, for example, can now authenticate a 100K
file in 3.2 seconds on an IBM "AT"-class machine running at 10 Mhz
without any extra hardware or fancy disk drives. This is best done by
applying a judicious combination of DES encryption with CRC techniques
on a random sampling of file contents, rippling the cryptographic
residue through the entire calculation with a technique that crypto
people call "cipher-block chaining". Furthermore, files don't need to
be checked every single time they are used, so these modest delays
need not occur more than a few times per month per file.

While I'm rambling on, I can't resist the urge to comment on a related
subject. Paul Kerchen writes:

>   where does one store these checksums and their keys? if they
>   are stored on disk, they are vulnerable to attack....

and Y. Radai comments on "static" versus "dynamic" invocation of
signature calculation, leading to discussion of the various advantages
and disadvantages of storing keys and signatures (and maybe even
protection logic) on an active hard disk versus off-line storage on a
diskette.

In my experience, all of these viewpoints have advantages and
disadvantages, and a sophisticated defense must allow users to pick
and choose from all of these techniques according to his own needs. A
heirarchy of interlocking defenses must be put together, with "dialy"
or "dynamic" (continuous but random) checks acting as the first line
of defense based on an active hard disk, and with periodic (weekly or
monthly) off-line checks based on a "sterile kernel" stored on a
bootable diskette that's kept locked up when not in use. In essence,
the monthly checkup from the sterile kernel checks up on the defenses
that've been exposed to viruses in the "dirty" world....

So how 'bout it? Anybody against using respected industry standard
authentication algorithms? Anybody got a better idea?

(By the way, my comments should not be construed to represent any
official viewpoints of the American National Standards Institute. I'm
just a member of the working group....)

Bob Bosen
Vice President
Enigma Logic, Inc.
2151 Salvio Street #301
Concord, CA   94565
Tel: [phone]
Internet: [e-mail]

------------------------------

Date:    15 Nov 89 05:46:55 +0000
From:    [e-mail] (Bill Weston)
Subject: XTREE virus clarification... (PC)

 Just goes to show what I get for typing before reading..  (I should
have recognized the "Stoned" virus...

 XTREE.EXE *MAY* be a vector, however a more likely candidate is a,
pirated I suspect, version of Norton Utilities.  (I guess he got what
he paid for..)  Like I said, he is very new to the MS-DOS community
and really did not know the Norton Utils from Sub-Hunter...

 We sterilized his drive and isolated the infected disks.  However, I
would still like to know if anyone has a "CURE" program for it..

Bill Weston == ...!usceast!uscacm!12!Bill.Weston

------------------------------

Date:    15 Nov 89 02:21:24 +0000
From:    ttidca.TTI.COM![e-mail] (The Polymath)
Subject: Re: Sophisticated Viruses


[e-mail] (Kenneth R. van Wyk) writes:
}[e-mail] writes:
}
}>> ...in part because writing a virus that no one notices is not any
}>> fun.  If no one notices, then it is not possible to know about
}>> propagation or survival.  What fun is that?
}
}There's an important distinction to be made here - detection during
}propagation vs. detection after (presumably) successful propagation.
}A virus could well attempt to conceal its existence while propagating,
}and then do quite the opposite (!) during a destructive phase.  No one
}would notice until it would be too late.

Here's another scary thought.  All the viruses I've heard of so far
appear to be the work of malicious amateurs.  I can think of
motivations that might inspire a professional:

     An unfriendly government wants to cause dislocation in the United
     States.  It commissions a difficult to detect virus that spends 5
     years propagating, then wipes the hard disks of every machine it's
     on, without warning or explanation.

     A spy puts out a sophisticated virus that does no damage.  It just
     looks for modems on serial ports and sends what looks like sensitive
     information to a central collection point. (What sort of information?
     How about comm program macro files containing account IDs and
     passwords?)

I'm sure you can think of other scenarios.  So can "they", whoever
"they" are.

The Polymath (aka: Jerry Hollombe, [e-mail])  Illegitimis non
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   [phone], x2483
Santa Monica, CA  90405 {csun|philabs|psivax}!ttidca!hollombe

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 17 Nov 1989    Volume 2 : Issue 242

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

BITFTP confusion of yesterday
Virus or just hardware/software problem? (Mac)
Write protect tabs (was Re: CRC's)
Help needed on Mac virus attack (Mac)
possible bug in scanres46 (PC)
STONED Virus (PC)
Re: Signature Programs

---------------------------------------------------------------------------

Date:    Fri, 17 Nov 89 07:27:08 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: BITFTP confusion of yesterday

Hi folks,

Yes, I accidentally replied to a message yesterday, directly to the
entire list.  Again, I apologize for that.  I did learn that one of
the quickest ways to get help on something is to make a glaring
mistake like this.  :-)  Thanks to all those who sent in the HELP
information for BITFTP.  Allow me to explain...

FTP (File Transfer Protocol) is an Internet facility which, as the
name implies, allows users to transfer files between Internet hosts.
This facility is used frequently for making archives, programs, etc.,
available to the general public - the VIRUS-L/comp.virus archives are
available via anonymous FTP.  Traditionally, FTP was only available to
Internet subscribers since it relies directly on the TCP/IP network
protocol used on the Internet.

Enter BITFTP...  BITFTP is an email facility provided at PUCC
(Princeton University Computing Center) - perhaps other IBM VM/CMS
sites as well? - which allows users to invoke Internet FTP sessions
via email requests to [e-mail].  This gives BITNET and other
email networks (Usenet, etc.) access to much of the FTP facilities of
the Internet.  I say "much of" because the facility, in all its
usefulness, cannot currently transfer binary files, though real FTP
can.

Rather than include the lengthy HELP information for BITFTP here, I
refer readers who would like this information to obtain it on-line by
sending email to [e-mail] - in the email message, just enter
a line containing "HELP".  You will then receive the actual HELP file
provided by the service.

I hope this clears up the confusion.  BITFTP can provide a very useful
service to non-Internet sites.  As a disclaimer - BITFTP is not
provided by VIRUS-L/comp.virus, CERT, or any group that I'm associated
with; I know little more about it than what I've presented here, and
I'm merely pointing its availability out to users who might find it
useful.

Regards,

Ken

------------------------------

Date:    16 Nov 89 13:50:17 +0000
From:    [e-mail] (Mike McCann)
Subject: Virus or just hardware/software problem? (Mac)

I encountered a problem with a Mac Plus (Everex 20Mb HD, 6.0.3, 2.5Mb
RAM, QuickMail, Netway1000, SAM).  The system and finder were not
visible but the machine was still bootable (some software failed to
run or crashed).  When I used ResEdit from a locked disk I found two
DeskTops but no system or finder anywhere.  The person in charge of
Macintoshs for that area said he reinstalled all the software but the
problem reoccurs.  I immediately thought of a virus and scanned all
the disks and the Mac Plus with Disinfectant1.2 but found nothing (I
did find two file with damaged resource forks on the Mac Plus but
these were documents).

If anyone can offer any suggestions, I would greatly appreciate it.
(PS- I personally used Everex's HD formatter to erase the drive and
then installed new, known-clean system software on the Mac Plus with
his software (he didn't have known-clean copies of the software) and
I'm now waiting to see if strange things happen again).

Thanks
- --
Mike McCann       [phone]   Internet = [e-mail]
Poole Computer Center (Box P-21)       UUCP = gatech!hubcap!mmccann
Clemson University                   Bitnet = [e-mail]
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.

------------------------------

Date:    15 Nov 89 01:14:28 +0000
From:    munnari!stcns3.stc.oz.AU![e-mail] (Dave Horsfall)
Subject: Write protect tabs (was Re: CRC's)

In article <[e-mail]>,
    [e-mail] (Charles Kichler) writes:

| The advantage is hardware is difficult to modify via software.  As of yet,
| I haven't seen a program that can beat a write protect tab.

I have heard a story, perhaps apocryphal, of a disk controller whose
"write protect" mechanism merely set a bit in a register, which the
software was supposed to check.

Do you _know_ your write-protect tab really works?

[Ed. This question was discussed a few times on VIRUS-L/comp.virus;
the consensus was (after reviewing schematic diagrams) that the write
protect mechanism on PCs (and clones thereof) and Macs is implemented
in hardware and is thus not circumventable without hardware
modifications.  Unless someone can produce a definitive, reproducable
piece of code that can prove otherwise, lets all please consider this
to be the case.]

Dave Horsfall (VK2KFU),  Alcatel STC Australia,  [e-mail]
[e-mail],  ...munnari!stcns3.stc.oz.AU!dave

------------------------------

Date:    Thu, 16 Nov 89 09:19:27 -0500
From:    Tom Southall <[e-mail]>
Subject: Help needed on Mac virus attack (Mac)

Hello,

We are being hit by a Mac virus that is not recognized by our vaccine
programs (Disinfectant, etc.).  The symptoms we see, in order of
severity (age?) of the virus are:

1. System file date changes to current date
2. All printing services are degraded
3. File can not be opened - but is visible
4. Open files can not be saved
5. Machine freezes in the middle of doing work
6. Names of infected files are changed to *'s

The virus appears to be passed through data files and/or through our
Appletalk network.  We have reformatted all disks and fixed the
server, but the virus re-appears very quickly.

Any ideas as to what this might be, and how to get rid of it would be
greatly appreciated.  Thank you,

Tom Southall
Manager, User Services
The American University
Washington, DC  20016
[phone]

------------------------------

Date:    Thu, 16 Nov 89 15:55:20 -0600
From:    mitch cottrell <[e-mail]>
Subject: possible bug in scanres46 (PC)

To whom it may concern...

I do not wish to spread rumors....but??

Concerning the McAffee scanres and SCAN program, I am experiencing
unusual hardware problems at undetermined time lengths after
execution of these two programs (version 38 and 46) This problem
affects floppy disk drives only on base PC and XT systems.  The
faults appear to affect the disk drive motor and do not allow it to
run.  This problem does not appear in systems unless the programs a re
executed.  This problem is also cleared by a reboot or power cycle.

If anyone else has experienced similar problems please let me know...

PS.  I would hate to discover a new virus......

[Ed. Has anyone else had similar problems.  I'd suggest being *real*
hesitant to draw a conclusion on this without more similar
occurances.]

Reply [e-mail]
Acknowledge-To: <C2852@UMRVMB>

------------------------------

Date:    Thu, 16 Nov 89 17:31:32 -0500
From:    Mark Powers <[e-mail]>
Subject: STONED Virus (PC)

Two of our PC labs have been infected with the STONED virus.  Is there
anything out there that will fix these machines or are we looking at
rebuilding the infected disks?

                          Thanks for any assistance

                          Mark Powers
                          Academic Computer Service
                          Miami University
                          513-529-2020

------------------------------

Date:    Fri, 17 Nov 89 00:17:27 -0500
From:    Steve Woronick <[e-mail]>
Subject: Re: Signature Programs

   Bob Bosen <[e-mail]> brings up some interesting
points, asking why programmers writing authentification programs are
utilizing CRC and checksum algorithms rather than more sophisticated
algorithms like ANSI X9.9, ISO 8731-2, or DES.  I think it depends on
what you are trying to do.  If your plan is to encrypt your program and
rely on difficulties in decryption for protection against infection, then
it probably makes sense to use something very sophisticated, because you
want to make certain that no one but yourself can do the decryption.
If you are leaving the encrypted form on your disk (where it might be
compared with the unencrypted form which is surely to appear either on
your disk or in memory at some future date if you use it), you don't
want to be using something so simple that it might give your algorithm
away.

   On the other hand, if you are not encrypting your program but are
simply trying to generate a number (or maybe several numbers) for
authentification purposes, I don't see that it is necessary to use
anything more sophisticated than a polynomial.  If the virus doesn't
know your polynomial, then it's chances of guessing a sequence of
characters with which to "pad" your program file in order to generate
the same CRC value as the original unaltered program is quite
small.  Of course, everyone ought to be using a slightly different
algorithm (i.e. different polynomials) and ought to be hiding the
authentification algorithm.  Correct me if I'm wrong:  If the algorithm is
sophisticated enough that it is very hard for anyone to guess CRC values,
then there probably is no need to hide the values it calculates for each
of your program files; in principle, one might be able to deduce the
algorithm by comparing program files with the CRC values generated by the
algorithm, but this will work only if there is enough information
available for analysis (which will not be the case for sufficiently
high order polynomials).  The information in a CRC is small compared to
the information in an encrypted file, so CRC programs need not be
terribly sophisticated to foil discovery.

   It has been pointed out that doing a cold boot from a clean floppy
assures you that your system is running clean (i.e. there are no viruses
in memory --- there may be some on your hard disk, but these are dormant
until you run an infected program).  If you then run your
authentification program from the clean floppy disk on your clean system
to check your hard disk (or other), you can rest fully assured that no
virus etc. has had the opportunity to intercept your checking program
and fool you into thinking that an infected program is uninfected (unless
you were dumb and previously exposed the clean disk, though write-
protected, to the inquiring eyes of a virus).  And since there are no
viruses in memory, none can steal your checking algorithm or any of the
CRC values (which you probably are keeping on the clean disk; for that
matter you can keep your own personal polynomial coefficients on the
disk also).  You probably will wisely want to keep your clean disk
write-locked to prevent accidents, but infection is not the only threat
(so write protection does not fully protect one from accidents).  If one
runs the authentification program (or even accesses the disk it's on),
without first doing the cold clean boot, then one risks having the
authentification algorithm stolen by a virus.  And as has been stated
before, one cannot be certain of the authentification results if the
cold boot from the clean disk was not done.  Finally, you obviously have
to write to the clean disk once in a while to update the CRC-values list
for new programs/ whatever, but this is no problem because you're not
going access it without first doing the cold clean boot.  One of course
also assumes that your clean disk was really clean to start with.

   Any comments?  Here's a question:  What's a good reference for
finding out about ANSI X9.9 and ISO 8731-2?  I can give you one for DES
(Data Encryption Standard):  Numerical Recipes, The Art of Scientific
Computing, by W.H. Press, B.P. Flannery, S.A. Teukolsky, and W.T.
Vetterling, published by Cambridge University Press, (c)1986,
p. 214-220.  Two and one half pages of highly-inefficiently coded FORTRAN
is given which implements the DES algorithm (except that the standard
itself explicitly states that any implementation in software is not
secure and therefore not DES).
- -----------------------------------------------------------------------
Steven C. Woronick     | Disclaimer:  These are my own opinions.
Physics Dept.          |     Always check it out for yourself...
SUNY at Stony Brook    |
Stony Brook, NY  11794 |
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 17 Nov 1989    Volume 2 : Issue 243

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

eagle update (PC)
Help...Virus Attack (Mac)
Re: New Virus (PC) / Reported Possible Virus
Re: Virus or just hardware/software problem? (Mac)
Write protect tabs (was Re: CRC's)
RE: on CRCs

---------------------------------------------------------------------------

Date:    Thu, 16 Nov 89 19:06:00 -0500
From:    IA96000 <[e-mail]>
Subject: eagle update (PC)

Update on the virus contained in the file EAGLE.EXE.

1) It IS NOT new! It is Jerusalem B.
2) It IS infectious and will spread.
3) Scan WILL NOT detect the virus UNTIL EAGLE.EXE is run, at
   which time the /M command line switch for Scan picks up
   the virus during the memory check.
4) IF COMMAND.COM IS FOUND in the root directory of the drive
   EAGLE.EXE is executed from, the BOOT and FAT sectors are
   completely destroyed with the Hex 246 character! Several other
   sectors get destroyed at the same time. Jerusalem B is loaded
   into memory and waits silently.

5) If COMMAND.COM is notfound in the root directory, Jerusalem
   B loads into memory. No damage is done to the disk.

6) KISS AN EAGLE TODAY! is then printed to the screen.

   Not only is   the program EAGLE.EXE contain a live virus, it
is also a trojan in disguise, waiting to wipe the BOOT & FAT areas
clean.

   We are now checking to see if the trojan part of the program
is passed along when Jerusalem B is loaded into memory. In any
event, the file is DANGEROUS and care should be taken.

------------------------------

Date:    Fri, 17 Nov 89 10:37:00 -0500
From:    <[e-mail]>
Subject: Help...Virus Attack (Mac)

Please help!!

I work in an Apple computer lab at Central Connecticut State
University, and lately we've been having an outbreak of viruses (nVir
A).  I figured it out by using Disinfectant Ver. 1.1.

What should I do??  It is a public lab, so people are in and out all
the time some with their own disks.  We have all Mac SE's with 20 meg
HD hooked up through appletalk.  I tried using gatekeeper, but
programs such as Excel would not work.  I tried initializing all the
hard drives, and replacing them with the original software, but the
viruses keep coming back.  Also some of the people come in with their
own software that could be infected.

Any information on how I can control this problem would be greatly
appreciated.  You can contact me at: FELDMAN_GAL@CTSTATEU

Thanks,

Garry Feldman
Supervisor, CCSU Apple Computer Lab

------------------------------

Date:    16 Nov 89 10:13:00 -0500
From:    [e-mail]
Subject: Re: New Virus (PC) / Reported Possible Virus

Comment: About that "virus" reported to John McAfee [Virus-L Digest V2
#239] by Fred Hankel of Fargo, North Dakota, that

>> ... promply melted his power supply and mother board ... [and]
>> ... blasted a perfectly circular
>> hole in the front panel of his AT clone and left a three foot oval scorch
>> mark on the back wall of his den.

Er, doesn't anyone recognize a *L*I*G*H*T*N*I*N*G* strike?  The effects
Mr. Hankel reported are classic, only the assumption of a computer
virus is paranoia.

Maybe McAfee should submit this to the RISKS forum.
/s/:
Tom Zmudzinski             |      "The above does not constitute a policy
DCS Data Systems           |       statement from DCS Data Systems or its
McLean, Virginia           |       parent organization" - Zmudzinski
- ---------------------------+---------------------------------------------
[phone]             |      "But it does from Me!" - GOD


------------------------------

Date:    Fri, 17 Nov 89 13:05:43 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Virus or just hardware/software problem? (Mac)

I've seen this problem before, and it is not a symptom of any of the
known Mac viruses.  While I never found what the specific problem was,
my speculation was that it was some defect in the media.  I suggest
you backup the data files on your disk, reformat it, and reinstall the
software.

------------------------------

Date:    Fri, 17 Nov 89 09:51:38 -0600
From:    "Craig Finseth" <[e-mail]>
Subject: Write protect tabs (was Re: CRC's)

   [e-mail] (Charles Kichler) writes:

   ...

   Do you _know_ your write-protect tab really works?

   [Ed. This question was discussed a few times on VIRUS-L/comp.virus;
   the consensus was (after reviewing schematic diagrams) that the write
   protect mechanism on PCs (and clones thereof) and Macs is implemented
   in hardware and is thus not circumventable without hardware
   modifications.  Unless someone can produce a definitive, reproducable
   piece of code that can prove otherwise, lets all please consider this
   to be the case.]

I would like to confirm the "Ed." tack-on for IBM PCs, clones, and
Macs.  However, early Apple ][s *did* implement this feature in
software.

I don't know for sure, but believe that later (=current) Apple ][s,
Ataris, and Amigas perform this function in hardware.

Craig A. Finseth            [e-mail] [CAF13]
Minnesota Supercomputer Center, Inc.    [phone]

------------------------------

Date:    Fri, 17 Nov 89 10:40:00 -0600
From:    david paul hoyt <[e-mail]>
Subject: RE: on CRCs

  This is really in response to the CRC auto-diagnosis letters
recently, but it was prompted by Bob Bosen's November 16th article.

 Mr. Bosen points to very good documents that will point the serious
anti-viral minded software developers to an excellent method of
defending their software (and customers) from viruses.  I would
suggest that software developers should at least review these
documents.

  However, I would like to add a comment.  Any of these auto-check
schemes rely on a small number (1 to n) of programmed checks to see if
the software has been corrupted.  While this will defend against a
general purpose or unsophisticated virus, it has little value against
a malicious attack against your product.

  About ten years ago, there was a game called dungeon, that ran under
VMS and perhaps other machines as well.  Dungeon had something called
'game master mode.' You could rearrange things (cheat) to your heart's
content.  Figuring out how to use 'game master mode', figuring out its
data structures, parsers and whatnot was much more interesting and
educational than the game it self.  But I digress.

  You entered it by saying something (incant?) and it would issue you
a challenge. It gave you a word, and you had to decrypt it.  Knowing
nothing about cryptanalysis, I might of been out of luck.  But rather
than figuring out the cipher, I merely found the routine that checked
to see if your response was correct and patched it to always return
true.

  If I could figure this out as a complete novice (that was the first
year I had seen a computer) think what a disgruntled employee might be
able to do.

  The solution is, of course, to put part of the check someplace other
than in the computer.  The user can, even without his knowledge, be an
integral part of the check.  In the Mac world, and probably other
worlds as well, when you first open an application, it asks you your
name and your company. It then stores that data someplace, and each
subsequent time you open the program it proclaims "This program is
licensed to My Favorite Person."  Or what ever else you happened to
answer.

  The long and the short of it, is this: that name can be used as the
key, along with the checksum, signature or whatever else you use, to
encrypt itself. The CRC, exclusive or'ed with the odd bytes of the
name can be used to create a key to to decode the even bytes of the
name.  Or any other like method.  The individual's name will then be
part of the correct 'signature' for the program.  And the best part of
it is that it will be the user, not the program, that performs the
final authentication.  If the user see's

   "This program is licensed to M# Fpv9r`ta.eas*n"

Then she will know something's afoot.  And there is nothing the
vandals can do about it.  The virus will be detected.

david hoyt | [e-mail] | [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 20 Nov 1989    Volume 2 : Issue 244

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Virus Stoned and Jerusalem - B (PC)
Re: Sophisticated Viruses
Virus Disinfectors (PC)
Re: Reverse engineering CRC validation code.
Re: Help...Virus Attack (Mac)
EAGLE.EXE Virus (PC)
Internet worm impact (UNIX & Internet)
Re: Sophisticated Viruses (Mac)
The Brain...again (PC)

---------------------------------------------------------------------------

Date:    Fri, 17 Nov 89 19:12:52 +0000
From:    [e-mail]
Subject: Virus Stoned and Jerusalem - B (PC)

Can anyone help? We have recently discovered that a cluster of about
12 Pc`s have become infected with the above mentioned viruses.  What
preventative action can we take and is there any simple way of
removing the viruses without destroying data?  Is any software
available to do this?
   The STONED virus is a boot-sector virus and the other one seems to
have attached itself to various .com and .exe files.
   Any help and advice would be much appreciated.

                   R.Gowans
- -----------------------------------------------------------------------------
JANET:       [e-mail]
Internet:    [e-mail]     Dept Civil Eng,
EARN/BITNET: R.Gowans%MCC.ac.uk@UKACRL              U.M.I.S.T,
UUCP:        ...!ukc!umist!R.Gowans                 Sackville Street,
                                                    Manchester.
FAX:         [044 61  | 061] 200-4016               M60 1QD.

------------------------------

Date:    17 Nov 89 21:51:32 +0000
From:    wugate!attctc.Dallas.TX.US![e-mail] (Jon Hutto)
Subject: Re: Sophisticated Viruses

In article <[e-mail]> ttidca.TTI.COM!hollombe%sdc
[e-mail] (The Polymath) writes:
>[e-mail] (Kenneth R. van Wyk) writes:
>}There's an important distinction to be made here - detection during
>}propagation vs. detection after (presumably) successful propagation.
>}A virus could well attempt to conceal its existence while propagating,
>}and then do quite the opposite (!) during a destructive phase.  No one
>     An unfriendly government wants to cause dislocation in the United
>     States.  It commissions a difficult to detect virus that spends 5
>     years propagating, then wipes the hard disks of every machine it's
>     on, without warning or explanation.

This is scary. A Virus writen by someone who knows what they are doing
coulsd be very dangerous. Or even one by someone who knows more than
viruse writers at any rate.

One writen by a non-friendly government would be especaly bad. Forget
the cold war, this is the Technical war, between Super computers. We,
the users would really be caught between a rock and a hard place.
Nothing we could do, but watch them destroy each other.

Could you imagine someone who knows IBM-PC ASM well, like Peter
Norton, or McAfee writing a virus? (completly hypathetical, no hidden
meaning) It would be the worst virus to hit ANYONE.

  Jon Hutto     PC-Tech BBS  [phone]     2400 baud

USENET:    {ames, texbell, rutgers, portal}!attctc!hutto
INTERNET:  [e-mail]  or  attctc![e-mail]

------------------------------

Date:    Fri, 17 Nov 89 09:35:59 -0800
From:    portal!cup.portal.com![e-mail]
Subject: Virus Disinfectors (PC)

    There have been a number of questions on Virus-L in the past few
weeks about "cures" for the various infections that have been
reported.  While not all infections can be "cured" without the loss of
some or all of the infected programs, there are a number of
disinfectors that can remove the more common viruses and repair the
damage to the infected application in many cases.  Disinfectors
available on HomeBase (408 988 4004) are:

    Dark Avenger          - M-DAV.ARC
    Traceback/3066        - M-3066.ARC
    Vienna                - M-VIENNA.ARC
    Ping-Pong (all vers.) - MD.ARC
    1701                  - M-1704.ARC
    1704                  - M-1704.ARC
    1704-C                - M-1704C.ARC
    Jerusalem             - M-JRUSLM.ARC
    Stoned                - MD.ARC
    Ghost (Boot seg.)     - MD.ARC
    Brain                 - MD.ARC (bootable diskettes only)
    Alameda               - MD.ARC           "
    Den Zuk               - MD.ARC           "
    Disk Killer (Ogre)    - MD.ARC

    For all other viruses, the ViruScan (versions 48 and above) /D
option will overwrite all infected files with C3H and then delete the
file.  This will effectively remove the virus from the system, but
infected applications will be deleted.  It'll save a re-format though.
    If you are looking for a non-shareware (yuch!!) solution, then the
VirClean program is an integrated package that does just about all of
the viruses.  Seems to work but requires money.

Alan

------------------------------

Date:    Sat, 18 Nov 89 08:55:09 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Reverse engineering CRC validation code.

In VIRUS-L Digest V2 #243, David Hoyt ([e-mail])
speculates about patching an internal CRC check for authentication to
always return "True".

I would like to counter that a virus designed to defeat an internal
consistency check in this manner would not be a very good infector.
It would have to rely upon either (1) always knowing where to find the
consistency check or (2) always being able to *find* the consistency
check.

In the former case, the virus would only be able to infect files would
be limited to the number of files it knows about, and the more files
it would know about would cause the virus to be larger and larger.
The larger the file, the more likely the virus will be detected by a
simply size check.

In the latter case, the virus would be unnecessarily cumbersome
because of the needed search code to find the consistency check,
again, increasing the likelyhood of detection because of the size of
the code needed to do the search and any delay caused by the virus
performing the search.  Also, the virus would be limited to attacking
files with the targeted consistency check.  If the check is subtly
varied from one file to the next, the search would have to be even
more complicated.

None of this says such an infector is not possible, just that it would
be a poor infector.

------------------------------

Date:    18 Nov 89 22:31:27 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: Help...Virus Attack (Mac)

Garry Feldman, Supervisor, CCSU Apple Computer Lab, writes about his
problems fighting viruses in a public access computer lab and mentions
a problem that forced him to abandon the Gatekeeper anti-virus system:

>I tried using gatekeeper, but programs such as Excel would not work.

Judging from this description, you need to use the current version of
Gatekeeper, 1.1.1.  It's been out since 26-June and can be found in
the sumex info-mac archives.  The problem, for the record, was in
Excel - not Gatekeeper.  Nonetheless, I coded around that problem (and
a number of others) in the interest of sparing people just the sort of
problems you've experienced.  So give 1.1.1 a try - I think you'll
find that it works well.

By the way, the Computation Center here at U.T. has installed
Gatekeeper on all the Macs (33 of 'em) in its public access
microcomputer lab, and found it completely effective.

Of course, if users insist on starting Macs from their own disks,
Gatekeeper is effectively out of the picture.  In practice, though, we
don't have much trouble with that since (a) users tend to need
software like the LaserWriter driver and the UserInfo RDEV that tend
to be unique to the disks we provide, and (b) we scan the disks
checked out to each user with Disinfectant 1.2 after the user leaves -
if we find the disks are infected, that student (whose ID number was
logged when they checked-in) is not allowed to use the facility again
until they've allowed us to clean their disks (we explain about
viruses and give them copies of Disinfectant and Gatekeeper at that
time).

This approach has kept our lab completely clean, and has
*dramatically* reduced the number of viruses present in our user
community.

Of course, this approach isn't possible in an unattended lab.  In that
environ- ment, you have to depend on automatic systems like Gatekeeper
almost entirely.  And Gatekeeper works extremely well in such
environments.  Even if some users start Macs from their own, infected
disks and thereby infect your lab's Macs, Gatekeeper is still valuable
since it will protect later users who do startup from your disks from
the viruses left behind by the other users.

I hope this helps,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Sat, 18 Nov 89 13:45:21 -0800
From:    portal!cup.portal.com![e-mail]
Subject: EAGLE.EXE Virus (PC)

    The EAGLE.EXE virus reported by Wakeem Rashad was not detected by
SCAN because the Jerusalem Virus (and the trojan it was attached to)
had been purposely compressed into a self extracting EXE file by a
program called AXE (from SEA Systems, Wayne, NJ).  This program has
been used by a number of crackers to try to plant infected software
onto bulletin board systems.  There is unfortunately little that can
be done to detect viruses in these AXE'd EXE files.  The virus will be
caught as soon as it attempts to spread, since the next file it
attaches to will be infected in the normal manner.  It would be
possible to screen out all AXE'd files, but that would be detrimental
to the legitimate use of AXE by original program authors who wish to
decrease the size of their executable modules.
    If you have run one of these self extracting programs and suspect
a virus, run SCAN with the /M option to search for it in memory.
Alan

------------------------------

Date:    20 Nov 89 00:00:00 +0000
From:    David.M..Chess.CHESS@YKTVMV
Subject: Internet worm impact (UNIX & Internet)

Alan Roberts, commenting on Pam Kane's book, writes:

>                            We know that 50% of the connections were
> downfor 24 hours and some (including ARPANET) were down for up to 4
> days.

Do we really know that?  That sounds somewhat more severe than numbers
I've heard elsewhere.  ARPANET being down for 4 days is *certainly*
new news to me.  The most recent estimate on the number of systems the
worm actually ran on (and I'm afraid I've forgotten the source for the
moment!) was 2500; seems unlikely that that (or even the earlier 6000
figure) would have killed 50% of the links for 24 hours.  Are the
numbers you quote from any published source I could get and read?  The
(very early) reports in the Seeley, Spafford and Eichlin/Rochlis
papers didn't give me the impression that the impact on connectivity
was that severe, and one chronology says (attributing it to Stoll)
that the virus was "pretty much eliminated" by 1800 on 11/4, which is
only 48 hours after it was first noticed.

I'm not trying to argue that Alan is wrong, of course.  I'm only
surprised and curiosified by his numbers, and would like to read
whatever it was they came from.

DC

------------------------------

Date:    Mon, 20 Nov 89 15:37:18 +0000
From:    [e-mail] (Christer Ericson)
Subject: Re: Sophisticated Viruses (Mac)

[e-mail] (Joel B. Levin) writes:
>>I don't agree with you on any of these points, Terry. Say, on the
>>Macintosh all calls to ROM are done through trap vectors in RAM. These
>>trap vectors are patched by the system file (to fix bugs), by some
>>programs and by all anti-virus tools. However, it doesn't take a
>>genius to figure out that one could restore the trap vector to it's
>>original value and thereby bypassing the "safe" system.  . . .
>> . . . A patch like this wouldn't occupy much space and is quite
>>simple to write.
>
>Except that when system patches or INIT patches or program patches to
>the traps were removed by the virus (and how would the virus decide what
>value to restore them to?--this is different for each ROM and system
>release version) the user would certainly be likely to notice the
>resultant changed program behavior -- or system crashes.
>
>    /JBL

First, restoring the traps to their original values isn't that
difficult. These are initialized by the ROM, then there must be a
table from where all initial values are fetched from, right? As I
haven't been writing any viruses lately, I'm not sure if this table is
moving around from ROM version to ROM version, but attaining the start
address of this table for each and every ROM version isn't too
difficult. Also, the virus would of course restore the trap vector
after it's done, so why would there be crashes? Actually, it wouldn't
even have to change the trap vectors, it could call the ROM directly,
but I left that to your imagination to figure out (a fruitless
attempt, obviously) since I didn't want to give away freebies to
aspirant virus writers. Some things they'll have to figure out
themselves.

/Christer

| Christer Ericson                           Internet: [e-mail]  |
| Department of Computer Science, University of Umea, S-90187 UMEA, Sweden |
|     >>>>>    "I bully sheep. I claim God doesn't exist..."    <<<<<      |

------------------------------

Date:    20 Nov 89 10:37:00 -0400
From:    "WILLIAM HADLEY" <[e-mail]>
Subject: The Brain...again (PC)

I know the (C) Brain virus is not new...but it is back.  Both George
Mason University and Northern Virginia Community College have been
re-infected with the Brain virus.  From what I could tell by talking
to one of the consultants at GMU, this is the same version of Brain
that both schools were infected with before.  If it is, here is some
background data: It works on MS/PC DOS operating systems (at least up
to 3.3); this version will only infect 5.25" DS DD disks; once loaded
into a machine, it will infect EVERY 5.25" disk it comes in contact
with; it is only loaded when the machine is booted.

If anyone else (or any other school) is experiencing a re-infection of
the Brain virus, please send mail directly to me and let me know...I
would be interested.  Thanks in advance!!

Bill Hadley
[e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 21 Nov 1989    Volume 2 : Issue 245

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

re: Known PC Virus List (PC)
RE: Internet Worm Statistics...
Re: Ping Pong virus (PC) at UIUC
Eagle Virus Detection Utility and Final Report (PC)
No Virus Found (Mac)
Most common virus (PC)
More on VACSINA (PC)

---------------------------------------------------------------------------

Date:    20 Nov 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Known PC Virus List (PC)

Quite welcome for the format, and thanks for the acknowledgement!
A few small notes/questions:

   - I notice the "Missouri" and "Nichols" viruses aren't
     listed.   Did they turn out not to really exist, or
     to be viruses that are known under some other name?

   - For completeness, you might want to include the 1704-C,
     as well as the 1701, 1704, 1704-B and 1704-format?
     (The 1704-C has the same in-clear section as the
     1704-format, but doesn't have the disk-formatting
     code.)   I know you have a sample!  *8)

   - Suspect you didn't mean to mark "Self-Encryption" for
     the 1168 and 1280 viruses?  They don't do it in the same
     sense that the DataCrime II, the Syslock, or the 17xx
     series do; the only thing that's "encrypted" in the
     1168/1280 is the logo string, and that's just stored
     XORed with hex 55.  That's not the -interesting- kind of
     self-garbling: the kind that makes the invariant part of
     the virus smaller.

Nice list!

DC

------------------------------

Date:    Mon, 20 Nov 89 11:54:35 -0500
From:    [e-mail] (David Gursky)
Subject: RE: Internet Worm Statistics...

As some of you may recall, Cliff Stoll (author of "Stalking the Wily
Hacker" CACM May '88 and _The Cuckoo's Egg_ Doubleday 1989) asked
people to submit tales, horror stories, and so on about the Morris
Internet Worm.  Cliff then performed some statistical analysis on the
resulting data, and published the results as part of his paper "An
Epidemology of Viruses & Network Worms".  presented at the 12th
National Computer Security Conference last month in Baltimore (see
pages 371 -> 373 of the proceedings for the section of Cliff's article
on the Morris Work).

------------------------------

Date:    Mon, 20 Nov 89 16:40:30 -0500
From:    Melinda Varian <[e-mail]>
Subject: Re: Ping Pong virus (PC) at UIUC

Although I recognize that this is not the appropriate forum
for discussion of the BITFTP server, since BITFTP has been being
discussed here, I would like to correct some misapprehensions:

  BITFTP does handle binary files; indeed, it distributes hundreds
  of them everyday.

  BITFTP is currently designed to be used only within the BITNET/
  EARN/NetNorth network; it distributes all files (both binary and
  text) in NETDATA format, which means it cannot send files through
  mail-only gateways into other networks.

I have addressed the original complaint about BITFTP that was
broadcast to this list, i.e., that it was not accepting FTP requests
for the UXE.CSO node.  Requests to that node had regularly been
resulting in hung FTP sessions, but I believe that I have now
circumvented that problem, so I am again accepting requests to access
it.

Anyone wanting further information on BITFTP should send mail or an
interactive message to BITFTP@PUCC.

Melinda Varian

[Ed. Thanks for the clarification!]

------------------------------

Date:    Mon, 20 Nov 89 19:13:00 -0500
From:    IA96000 <[e-mail]>
Subject: Eagle Virus Detection Utility and Final Report (PC)

Final report on virus contained in file EAGLE.EXE:

1) It DOES contain a form of Jerusalem B. It WILL spread to other
   files once EAGLE.EXE has been loaded into memory.

2) If the system being run has a '286 or higher processor and if
   COMMAND.COM is found in the root directory, the program will
   DESTROY the boot and FAT tables on the disk. No question about
   this folks! It overwrites the sectors with the ASCII 246
   character.

3) When EAGLE.EXE is loaded, ONLY the Jerusalem B virus is spread
   to other files. The trojan part of the program is part of
   EAGLE.EXE, not part of the virus itself.

4) Viruscan (SCAN.EXE) WILL NOT detect any viruses in the EAGLE.EXE
   file. This appears to be because EAGLE.EXE has been compressed
   and a DOS loader has been added to the head of the file and is
   not the fault of Viruscan.

5) Once EAGLE.EXE has been run,SCAN will detect the Jerusalem B
   virus in memory when SCAN's "M" command line switch is used.

6) A write protect tab WILL stop the destruction of the Boot and FAT
   on a floppy. Numerous methods have been tried to stop the destruction
   of the Boot and FAT on a hard disk and none appear to be effective.

7) After considerable study it has been determined that the EAGLE.EXE
   program was written in (take a guess) a version of compiled Basic.

8) We have no way to know that author intended for the program to
   contain the Jerusalem virus. It is quite possible this IS the case
   since the specific compression program used would not allow the
   program to load, if the virus had infected the file AFTER it had
   been compressed.

To recap:

   The program name is EAGLE.EXE and contains the Jerusalem virus.
   It was uploaded to a BBS with a description line saying it would
   produce a VGA animation of an EAGLE in flight. If COMMAND.COM
   is present in the root directory of the default drive and if
   the processor is a '286 or higher (including a '486) EAGLE.EXE
   will write over the Boot and both FAT areas with the ASCII 246
   character.

Detection:

   The good people at SWE have written a small program named
EAGLSCAN.EXE which will probe any file with an extension of .EXE
to determine if it is the EAGLE.EXE program renamed. I do not know
the particulars of the program but I have tested it, and it is very
fast! It will if you desire scan one .EXE file or all .EXE files
on your disk. If a file is found be EAGLE.EXE renamed or has the
exact same identification strings, it will be flagged and you will
be notified.

If you would like a copy of EAGLSCAN.EXE please send a formatted
5.25 inch, 360k disk to the following address with return postage,
(stamps are fine) and you will receive the program along with a
commented dis-assembly of the EAGLE.EXE file. Please enclose a
return address label for the disk mailer.

                                       SWE
                                       132 Heathcote Road
                                       Elmont, New York 11003

EAGLSCAN IS NOT Shareware, nor is it in the public domain. The
authors have consented to supply anyone who reads Virus-L with
a copy free of charge (except for postage which you must supply).

That is about it for now. As far as I am concerned we have found
everything we need to know. EAGLE.EXE contains both a virus and
a very nasty trojan horse if the conditions are right!

For whatever it is worth, my opinion is that you should send for
a copy of EAGLSCAN. It does not cost you anything except for postage
and it might come in handy!

------------------------------

Date:    20 Nov 89 15:09:00 -0800
From:    harvard!applelink.apple.com![e-mail]
Subject: No Virus Found (Mac)

To put everyone's mind at ease:

In Virus-L Digest #242 Tom Southall of American University asks help
with an apparent virus problem. I was able to go down to American
University today and take a look at the Macs there. I could find no
evidence of any viral activity.  What I did find was some things put
onto the systems by students and set to be invisible. These definitely
accounted for the changing system file size, and perhaps for the other
problems experienced there.

Paul Cozza

------------------------------

Date:    21 Nov 89 14:16:38 -0400
From:    <[e-mail]>
Subject: Most common virus (PC)

Can we know which type of VIRUS is most common on the Personal Computer ?

Thank in advance

------------------------------

Date:    Tue, 21 Nov 89 06:02:39 -0500
From:    <[e-mail]>
Subject: More on VACSINA (PC)

Hi,
  we just completed our virus catalog entry for the VACSINA virus and
checked with some friends. One of them: David M. Chess pointed out
that we overlooked a fact. Well it is a very important fact: VACSINA
contains an update facility.  The last 4 bytes of an infected file
contain F4 7A 05 00. The F4 7A is the VACSINA id and 05 00 is the
version number ( lo byte first ) so we have version 0005 of VACSINA.
If the virus finds anything less than 0005 it will reconstruct the
original file and then it will infect with the new version of VACSINA.
Now we understand why the author left so much space in the head of the
virus. Also the 3 byte used for the 'VACSINA-TSR is in memory' flag
contain a 05 so future versions of VACSINA will know if an older
version of VACSINA installed its TSR.
If anybody has virus infected files that show F4 7A 06 00 or higher
please post a note.
Thanks to David again!
Chris
*****************************************************************
* Torsten Boerstler and Christoph Fischer and Rainer Stober     *
* Micro-BIT Virus Team / University of Karlsruhe / West-Germany *
* D-7500 Karlsruhe 1, Zirkel 2, Tel.: [phone] or 2067   *
* E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET    *
*****************************************************************

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 21 Nov 1989    Volume 2 : Issue 246

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Known PC virus list
Where did they come from ? (PC)
A new LISTSERV group
Re: 80386 and viruses (PC & UNIX)
Re: 80386 and viruses (PC & UNIX)
CVIA clarifications
followup on mind viruses
Virus Disinfectors (Mac)
Potential Virus? (Mac)
Computer Virus Catalog Index:November'89

---------------------------------------------------------------------------

Date:    Tue, 21 Nov 89 16:25:22 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Known PC virus list

A few comments:
   - since the boot part of the ghost virus does not spread,
     it can not properly be called a virus, so I do not think it should be
     included.

   - The Pentagon virus does not work. Why include it ?

   - Why not include Agiplan, Oropax, Missouri, Macho and Nichols ?

   - Do-nothing Remains resident

   - 1168/1280 do not use self-encryption.

Apart from this it's a good list.

- -frisk

------------------------------

Date:    Tue, 21 Nov 89 16:26:30 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Where did they come from ? (PC)

I am trying to compile a list showing where the various viruses seem
to have originated. Here is what I have got so far, but I am sure the
list contains several errors, and I would be very grateful for any
comments and corrections.

Boot Sector Viruses:

        Alameda                   USA
        Brain                     Pakistan ?
        Den Zuk/Ohio              Venezuela ? Indonesia ?
        Disk Killer               USA ?
        Stoned                    New-Zealand/Australia
        Missouri                  USA ?
        Nichols                   USA ?
        Pentagon                  UK ?
        Ping-Pong                 Italy (Torino ?)
        Typo                      Israel
        Swap                      Israel

Program Viruses

        Aids                      USA
        Agiplan                   W. Germany
        Alabama                   Israel ?
        April 1st                 Israel
        Cascade                   USA ?
        Dark Avenger              ?
        DataCrime                 W. Germany ?  The Netherlands ?
        DataCrime-2               ?
        dBase                     USA
        Do-Nothing                Israel
        405                       UK ?
        Fumble                    USA
        Fu Manchu                 UK ?
        Ghost                     Iceland
        Icelandic/Saratoga        Iceland/USA
        Jerusalem/variants/Sunday Israel/USA
        Lehigh                    USA
        Mix1                      Israel
        Oropax                    W. Germany
        Screen                    USA
        South African             South Africa
        SysLock/Macho/Advent      W. Germany
        Traceback                 ?
        Vacsina                   W. Germany ?
        Vienna/Lisbon             Austria/Portugal
        Yankee                    ?
        Zero Bug                  ?

- -frisk

------------------------------

Date:    21 Nov 89 00:00:00 +0000
From:    BAUMARD.Philippe.42.64.31.89.BAUMARD@FRAIX11 (33)
Subject: A new LISTSERV group

Dear Virus-L networkers,

a new list has been created. Its name is APOGEES (LISTSERV at FRMOP11.BITNET).

APOGEES is open to any networker with practical experience in the
fields of strategic and critical information management. We are by
now working on supervisory systems for strategic technological
information.

Applicants are welcome. Please send a note to BAUMARD at FRAIX11.

Virtually,

APOGEES Management.

------------------------------

Date:    21 Nov 89 17:49:52 +0000
From:    [e-mail]
Subject: Re: 80386 and viruses (PC & UNIX)

[e-mail] (Peter da Silva) writes...
>> The isolation hardware in the I386 makes it possible to construct a
>> contained execution environment...  Such an environment would be a
>> useful place to test untrusted programs.
>
>> Has anyone constructed such an environment?
>
>Yes.
>
>It's called "Merge 386" or "Vp/IX".
>
>[Ed. These products, by the way, are DOS emulation boxes for i386
>based UNIX and XENIX products.]

Would someone elaborate on this?  Surely a program (virus or otherwise)
running under the emulator could do the same things, including deleting all
the files it can find, as on DOS.  What protection is provided?  Perhaps
not allowing access to the FAT, boot sector, etc.?

------------------------------

Date:    Tue, 21 Nov 89 13:46:23 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Re: 80386 and viruses (PC & UNIX)

>> Would someone elaborate on this?  Surely a program (virus or otherwise)
>> running under the emulator could do the same things, including deleting all
>> the files it can find, as on DOS.  What protection is provided?  Perhaps
>> not allowing access to the FAT, boot sector, etc.?

At least in the case of VP/ix (which I used on a Zenith 386 SCO Xenix
system when I worked at Lehigh), all DOS calls are subject to
"approval" by Xenix - or UNIX for that matter, on a 386 UNIX system.
All interrupts, etc., are handled by Xenix in the end.  The DOS
session(s) runs as a virtual 8086 on the 386, and is given an image
file which appears to be a physical hard disk to the DOS session.  The
"boot sector" per se is just part of a file on the Xenix file system
(or on a floppy if the VP/ix system is rebooted from floppy).  I would
imagine that this logical physical (?!) drive would be subject to boot
sector infections, but the actual Xenix disk is treated as a network
disk.  If a VP/ix process tries to delete or alter any of the Xenix
files, it would be subject to standard Xenix file protection
mechanisms.  I never did try to perform any direct (via hardware) read
or writes on the hard disk, but I suspect that they would be stopped.
Can anyone confirm this?

One interesting side-effect of the way VP/ix works is that a
(ctrl-alt-del) reboot really works - and can, in fact, be used to
reboot from floppy.  The VP/ix session boot DOS, while leaving the
Xenix system quite in-tact.  Very disconcerting the first time it's
done.

Running a DOS emulator under UNIX (or Xenix), in my opinion, would be
a very expensive anti-virus tool.  To me, there are plenty of other
good reasons to run UNIX on a 386 or 486.

Ken

------------------------------

Date:    Mon, 20 Nov 89 23:04:16 -0800
From:    portal!cup.portal.com![e-mail]
Subject: CVIA clarifications

Original-Date: 11-20-89 18:10:56
Original-From: John McAfee

        I regret that Ross Greenberg and three of my other competitors
mentioned in his statement persist in an attitude of hostility toward
myself and my endeavors.  I have no answer to Ross's allegations that
could possibly suffice, other than that my own recollections of the
events he described differ radically from his descriptions.  I must
set the record straight on two points however: First, Ross states that
the CVIA sells anti-viral software and that SCAN is one of its
products.  The CVIA does not sell any product, SCAN or otherwise, and
has never sold any product.  It is a non-profit corporation funded
solely by the membership and its only other source of income is
through the distribution of a public information packet (price -
$4.00; cost to produce - $4.70).
  Second, Ross states that the CVIA is an organization of antiviral
product vendors.  This is entirely incorrect.  The majority of members
are computer manufacturers or software houses with no existing or
planned antivirus products as part of their product lines.  It is true
that the beginning membership was composed of antiviral product
vendors, but the understanding from the beginning was that the
organization must have (and indeed now has) a broad industry
participation.

John McAfee

------------------------------

Date:    Tue, 21 Nov 89 10:10:03 -0700
From:    Peter Zukoski <[e-mail]>
Subject: followup on mind viruses

Dear virus-folk:
thanks for all the responses to Richard Dawkins questions. Here's some
further thoughts from Richard on the topic of mind viruses...He and I
would be interested in your opinions, especially on evolving/mutating
virus technology. Has anyone seen viri which evolve, or mutate in
response to the environment which it is in? Or viri which recognize
and "use" other viri which might be present?

OK Richard, you may begin...
- ----------------------------
There is something important about the distinction between what I call
Anarchic Replicators and Socialized Replicators.  In the world of DNA,
anarchic replicators are things like viruses, or smaller units with
names like viroids or plasmids, which parasitically exploit the
large-scale transcribing and copying machinery in cells, machinery
which has been put together by cooperating teams of socialized
replicators.  Socialized replicators are the ordinary mainline genes
that travel from generation to generation in sperms or eggs and
cooperate to build big survival-machines like our bodies.  In a sense,
our 'own' genes are parasitic on each aother's efforts, just as virus
genes are parasitic on the efforts of other genes.

In the world of mind viruses, the reason large religions like Islam or
Roman Catholicism fascinate (as well as repel) me is that they are
large aggregations of mutually socialized viruses, which work to
sustain other members of the cluster and work to destroy alternative
replicators.  e.g. Islam has a rule that apostates must be punished by
death.  The rule of priestly celibacy in Catholicism at first sight
doesn't seem like a self-preserving replicator. But it frees the
priest's time for more active proselytizing, and it enjoys a good
mutualistic relationship with another rule of contraception among
non-priests.

In the world of computer viruses, I find it harder to find an analogy
for socialized replicators.  I gather that anti-virus programmers have
already used the 'biological control' self-replication technique -
sending in a tame,'good' virus to catch the bad one.  This reminds us
of the possibility of a kind of ecology of computer viruses building.
We are reminded of this, again, in another of the papers which states
that viruses that were originally intended to be benign can turn
unintentionally malignant when the user upgrades to a new Operating
System.  A given OS serves as an environment in which a virus may
flourish or not, may behave benignly or malignantly.  Couldn't we
envisage a time when the whole computer environment facing a new virus
is put together, not just by one monolithic OS, but by the OS plus a
motley collection of aleady-infiltrated viruses, some benign, some
malignant, s ome medicinal.  New viruses will be written to flourish,
not just in known OSs, like System 6, System 7 and so on, but in a
background containing an unknown but statistically guessable
collection of already existing viruses.  Already, the environment that
even a legitimate programmer has to cope with is more than just the
operating system - think of the motley collection of co-resident INITs
and Desk Accessories that you have to worry about when writing a
program for public consumption.  A virus ecology will just complicate
the picture, in the same 'biological' direction.  The language I am
now using is not too far from the language that I use (e.g. in The
Selfish Gene and The Extended Phenotype) to describe the co-evolution
of genes in genomes.

So far, as far as I know computer viruses don't evolve.  Even with
viruses manufactured by conscious human programmers, something like a
mutually co-evolved cluster of viruses could come to constitute the
environment to which any future virus has to accommodate itself.  If
truly evolving (self-modifying in adaptive directions) viruses start
to arise, the trend will go even further.  Software Companies may have
to write their products to be compatible, not just with numbered
versions of 'The System', but with the changing statistical ensemble
of fellow-travellers both good and bad.

I'd be interested in hearing whether any of this makes sense.
Richard
- -----------------------

"Do what you want -- you will anyway."
PeterZ

------------------------------

Date:    21 Nov 89 14:06:19 -0500
From:    Pat Ralston <[e-mail]>
Subject: Virus Disinfectors (Mac)

Thanks to Alan for his contribution on Fri. Nov. 17th.  Listing many
or all of the Virus Disinfectors and the viruses associated with
them was a big help and a time saver.  Hunting through the back
issues of this list for specific information is becoming an unruly
task for me.

Now will some one do the same kind of list for the Mac? Thank you
in advance.

Pat Ralston

------------------------------

Date:    Tue, 21 Nov 89 14:53:48 -0500
From:    [e-mail]
Subject: Potential Virus? (Mac)

I have just recently noticed a problem on my Mac. After using Cricket
Graph I checked the last modified date and the program had just been
modified.  After noting this, I began checking other programs and
found that my copy of Versaterm Pro was also being modified every time
I ran it. It was at that point that I checked these programs on other
people's Macs in the office and saw that these programs were not being
modified on some, while they were being modified on others.. I am
running Gatekeeper and Vaccine and have checked these programs with
Disinfectant and they report no trouble.

My question is: Should these programs modify themselves when I just
run them.  All I do is run them and quit immediately and they are
modified??? Do you think I have a virus problem???

Joel Glickman
Rensselaer Polytechnic Institute.

------------------------------

Date:    21 Nov 89 17:42:00 +0100
From:    Klaus Brunnstein <[e-mail]>
Subject: Computer Virus Catalog Index:November'89

The Computer Virus Catalog now classifies 45 viruses
(AMIGA:24;MSDOS:15; Atari:6). Activities are undertaken to make the
documents available via servers in different regions of the world; we
hope that we can announce such servers in the next weeks. If you wish
to receive the documents (see Index appended, with length of the
documents given) sooner, please send a short request to the author.

Klaus Brunnstein

========================================================================
==                     Computer Virus Catalog Index                   ==
========================================================================
==        Status:        November 15, 1989 (Format 1.2)               ==
==        Classified: 15 MSDOS-Viruses (MSDOSVIR.A89)                 ==
==                    24 AMIGA-Viruses (AMIGAVIR.A89)                 ==
==                     6 Atari-Viruses (ATARIVIR.A89)                 ==
== Updates   since last edition (July 31, 1989) marked: U (column 70)=U=
== Additions since last edition (July 31, 1989) marked: + (column 70)=+=
========================================================================
== Document MSDOSVIR.A89 contains the classifications of the          ==
== following viruses (1.138 Lines, 6.271 Words, 62 kBytes):           ==
==                                                                    ==
==  1) Autumn Leaves=Herbst="1704"=Cascade A Virus                    ==
==  2) "1701" = Cascade B = Autumn Leaves B = Herbst B Virus          ==
==  3) Bouncing Ball = Italian = Ping Pong= Turin Virus              =U=
==  4) "Friday 13th" = South African Virus                           =+=
==  5) GhostBalls Virus                                              =+=
==  6) Icelandic#1 = Disk Crunching = One-in-Ten Virus               =U=
==  7) Icelandic#2 Virus                                             =+=
==  8) Israeli = Jerusalem A Virus                                   =U=
==  9) MachoSoft Virus                                               =+=
== 10) Merritt = Alameda A = Yale Virus                               ==
== 11) Oropax = Music Virus                                           ==
== 12) Saratoga Virus                                                =+=
== 13) SHOE-B v9.0 Virus                                              ==
== 14) VACSINA Virus                                                 =+=
== 15) Vienna = Austrian = "648" Virus                               =U=
==                                                                    ==
== Remark: The following 13 MS-DOS-Viruses are presently being classi-==
== fied and will be published in the next edition (December 31,1989): ==
==   .) Brain A = Pakistani A-Virus          (Pakistani Virus Strain) ==
==   .) Datacrime I = 1168 Virus             (Datacrime Virus Strain) ==
==   .) Datacrime II = 1280 Virus            (Datacrime Virus Strain) ==
==   .) Den Zuk Virus                 (Venezuela/Search Virus Strain) ==
==   .) Lehigh Virus                                                  ==
==   .) FuManchu Virus                         (Israeli Virus Strain) ==
==   .) NewZeeland= Marijuana= Stoned Virus (NewZealand Virus Strain) ==
==   .) Pentagon Virus                                                ==
==   .) SURIV 1.01,2.01,3.00 Viruses           (Israeli Virus Strain) ==
==   .) Traceback Virus                                               ==
==   .) 405 Virus                                                     ==
========================================================================
== Document AMIGAVIR.A89 contains the classifications of the          ==
== following 24 viruses (2.272 Lines, 9.421 Words, 106 kBytes):       ==
==                                                                    ==
==   1) AEK-Virus = Micro-Master Virus (SCA Virus Strain)            =U=
==   2) BGS 9-Virus                                                  =+=
==   3) Byte Bandit Virus                                            =U=
==   4) Byte Bandit Plus Virus (Byte Bandit Virus Strain)            =+=
==   5) Byte Warrior#1 Virus = DASA-Virus (Byte Warrior Strain)      =U=
==   6) Disk Doctors Virus                                           =U=
==   7) Gaddafi-Virus                                                =U=
==   8) Gyros Virus                                                  =U=
==   9) IRQ-Virus                                                    =U=
==  10) LAMER (Exterminator) Virus                                   =U=
==  11) LSD Virus (SCA Virus Strain)                                 =+=
==  12) NORTH STAR I  Antivirus-Virus (NORTH STAR Virus Strain)      =U=
==  13) NORTH STAR II Antivirus-Virus (NORTH STAR Virus Strain)      =U=
==  14) Obelisk Virus                                                =U=
==  15) Paramount Virus = Byte Warrior#2 Virus (Byte Warrior Strain) =U=
==  16) Pentagon Antivirus-Virus                                     =+=
==  17) Revenge 1.2G Virus                                           =+=
==  18) SCA-Virus                                                    =U=
==  19) System Z 3.0 Antivirus-Virus (System Z Virus Strain)         =U=
==  20) System Z 4.0 Antivirus-Virus (System Z Virus Strain)         =U=
==  21) System Z 5.0 Antivirus-Virus (System Z Virus Strain)         =+=
==  22) Timebomb 1.0 Virus                                           =+=
==  23) VKill 1.0 Virus = Camouflage Virus                           =U=
==  24) WAFT-Virus                                                   =+=
==                                                                    ==
==  Remark: the following 8 AMIGA-viruses are presently analysed, clas-=
==  sified and will be published in the next edition (12/31/1989):    ==
==   .) BUTONIC 1.1 Virus                                             ==
==   .) JOSHUA Virus                                                  ==
==   .) LAMER EXTERMINATOR Virus 1.0, 2.0, 3.0                        ==
==   .) SYSTEM Z 5.1, 5.3 Virus                                       ==
==   .) WARHAWK Virus                                                 ==
========================================================================
== Document ATARIVIR.A89 contains the classifications of the          ==
== following 6  viruses (375 Lines, 2.045 Words, 21 kBytes):          ==
==                                                                    ==
==             1) ANTHRAX = Milzbrand Virus                          =+=
==             2) c't Virus                                           ==
==             3) Emil 1A Virus = "Virus 1A"                          ==
==             4) Emil 2A Virus = "Virus 2A" = mad Virus              ==
==             5) Mouse (Inverter) Virus                             =U=
==             6) Zimmermann-Virus                                    ==
==                                                                    ==
== Since last edition, ANTHRAX V. has been added. We have problems to ==
== get viruses, as many users wish to exchange their viruses (like    ==
== stamps) against our's, which we generally refuse: the Virus Test   ==
== Center's ethical standard says, that we do not spread viruses!     ==
== Please send infected programs without preconditions.               ==
========================================================================
==  For essential updates (marked "U="), we wish to thank D.Ferbrache,==
==  Y.Radai and F.Skulason for their continued help and support.      ==
==  Critical and constructive comments as well as additions are       ==
==  appreciated. Especially, descriptions of recently detected viruses =
==  will be of general interest. To receive the Virus Catalog Format, ==
==  containing entry descriptions, please contact the above address.  ==
========================================================================

========================================================================
== The Computer Virus Catalog may be copied free of charges provided  ==
== that the source is properly mentioned at any time and location     ==
== of reference.                                                      ==
========================================================================
==  Editor:   Virus Test Center, Faculty for Informatics              ==
==            University of Hamburg                                   ==
==            Schlueterstr. 70,  D2000 Hamburg 13, FR Germany         ==
==            Prof. Dr. Klaus Brunnstein, Simone Fischer-Huebner      ==
==            Tel: [phone] (KB), -4715 (SFH), -4162(Secr.)    ==
==  Email (EAN/BITNET): [e-mail]   ==
========================================================================
==      This document: 117 Lines, 701 Words, 9 kBytes                 ==
========================================================================

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 22 Nov 1989    Volume 2 : Issue 247

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Sophisticated Viruses (Mac)
Anti-Virals (Mac)
Anti Virals, cont'd (Mac)
Re: Ohio vs. Den Zuk (PC)
Using Relay for real time conference
Comprehensive Virus Tools (PC)
Virus Attributes Listing
Any volunteers ? (PC)
High Level Language viruses
Corrections and new details on DataCrime (PC)
RE: Potential Virus? (Mac)
Self-modifying applications (Mac)
Re: Internet worm impact (UNIX & Internet)

---------------------------------------------------------------------------

Date:    21 Nov 89 18:26:07 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: Sophisticated Viruses (Mac)

[e-mail] (Christer Ericson) writes:

>First, restoring the traps to their original values isn't that
>difficult. These are initialized by the ROM, then there must be a
>table from where all initial values are fetched from, right? As I
>haven't been writing any viruses lately, I'm not sure if this table is
>moving around from ROM version to ROM version, but attaining the start
>address of this table for each and every ROM version isn't too
>difficult. Also, the virus would of course restore the trap vector
>after it's done, so why would there be crashes? Actually, it wouldn't

There would be crashes because it's very common for software that
patches traps to have interdependencies between its patches, i.e. one
patch depends on data discovered and stored for later use by another
patch.  Removing only a portion of such patches will be likely to kill
the machine sooner or later.  Even if you remove *all* patches, the
machine is still in grave danger since the INIT (or whatever did the
patching) may have changed some key characteristics of the machine
already - characteristics that it's patches would have isolated other
software from while they were installed and operating.

Further, restoring traps to their original values is going to remove
all of the patches put in place by the System itself - the patches
that keep that machine running inspite of bugs in the ROMs, etc.
Also, whole portions of the OS and Toolbox will be removed by
restoring traps to their initial values (as taken from the ROM) - this
will kill the machine for sure.  And even if you were to take the
status of the trap table at some point early in the boot phase (after
the key System patches had been made) and restore it much later (just
before the first application is loaded, say) you would still be
removing portions of the OS since the portions related to MultiFinder
are added *after* (not before) all the INITs are loaded.  Again, the
machine dies for sure.

Even if these changes to the trap table are temporary, the same
problems inhere - portions of the OS are fully installed and operating
while other portions have been partially or completely lobotomized by
restoring their trap table entries to some initial value.  Provided
there were no inter- dependencies between routines in the OS (not to
mention the Toolbox) this might not kill the machine immediately (but
it would likely kill it event- ually), but since there *are* such
interdependencies (often matched only in their importance by their
subtlety), the machine is going to die very quickly.

Writing well behaved patches is a black art on the best of days -
writing the sort of un-patching patches discussed here would make that
"black art" look like a carefree romp in the sunlit countryside.  I
don't think such patches could be implemented safely, and I don't
think anyone clever enough to do so would be wasting his time working
on viruses in the first place.

>even have to change the trap vectors, it could call the ROM directly,
>but I left that to your imagination to figure out (a fruitless
>attempt, obviously) since I didn't want to give away freebies to
>aspirant virus writers. Some things they'll have to figure out
>themselves.
>
>/Christer

All in all, I don't think the techniques dealt with in this discussion
are significant simply because there are too many reliability and
compatibility problems intrinsically linked to them.

For what it's worth,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Tue, 21 Nov 89 16:13:38 -0500
From:    Kim Dyer <[e-mail]>
Subject: Anti-Virals (Mac)

a Mac Antiviral list:

Antipan
Disinfectant 1.2
Gatekeeper  1.111
Interferon 3.1
Killscores
Killvirus-nvir
Repair 1.5
Rwatcher
Vaccine 1.01
Virus detective 3.01
Virus rx 1.4a2

All the above are available from the Info-Mac archives or various users
groups.  There are also several informational postings.

------------------------------

Date:    Tue, 21 Nov 89 16:30:52 -0500
From:    Kim Dyer <[e-mail]>
Subject: Anti Virals, cont'd (Mac)

I found more information on Mac Anti-Virals

There is a good write-up on 20 different Macintosh Antivirals in the
documentation for Disinfectant. I don't want to type it all in without
getting the author's permission.

I'm very pleased with Disinfectant.  Available from INFO-MAC archives
many users groups or the author.

     John Norstad
     Academic Computing and Network Services
     Northwestern University
     2129 Sheridan Road
     Evanston, IL  60208 - USA

     Bitnet JLN @ NUACC
     Internet JLN at ACNS.MWU.EDU
     Applelink A0173

------------------------------

Date:    22 Nov 89 00:36:26 +0000
From:    munnari!stcns3.stc.oz.AU![e-mail] (Dave Horsfall)
Subject: Re: Ohio vs. Den Zuk (PC)

[e-mail] (Fridrik Skulason) writes:

| As I have mentioned before, the "Ohio" virus contains the signature of
| the "Den Zuk", but it also contains some interesting text strings:
|
|                       V  I  R  U  S
|                            b y
|                        The Hackers
|                        Y C 1 E R P
|                       D E N Z U K O
|                       Bandung 40254
|                         Indonesia
|
|                 (C) 1988, The Hackers Team....
|
| Remember that Den Zuk puts the volume label Y.C.1.E.R.P on
| Brain-infected diskettes, when it removes the infection.

Just a long shot, but "YC1ERP" happens to be a legitimate Amateur
Radio (ham radio) callsign allocated to Indonesia...

I don't have access to an International Callbook just now.
Perhaps someone would like to check this out!

Dave Horsfall (VK2KFU),  Alcatel STC Australia,  [e-mail]
[e-mail],  ...munnari!stcns3.stc.oz.AU!dave

------------------------------

Date:    Tue, 21 Nov 89 19:40:00 -0500
From:    IA96000 <[e-mail]>
Subject: Using Relay for real time conference

Has anyone ever considered setting up a real time conference using
the Bitnet RELAY system?

I for one think it would be very interesting and educational for
everyone interested in viruses to get together and chat!

Well, the door is now open....Let's see if anyone enters.

------------------------------

Date:    Wed, 22 Nov 89 01:39:46 -0500
From:    "Eric Rowan" <[e-mail]>
Subject: Comprehensive Virus Tools (PC)

     I'm looking for comprehensive virus tools for the PC.  Frankly,
I'm looking for the PC world's analogy of the Mac virus
detector/disinfector Disinfectant as well as the analogy for a
preventative aid like Vaccine and GateKeeper....Hopefully these
analogies exist.  Please send any info, opinions and/or other comments
directly to me: [e-mail] Also, please include relevant
info like software availability (ie. shareware?) and the wheres and
hows on obtaining the software (eg. ftp addresses).  Thank you VERY
much.

Virtually,

Eric Rowan
Southern Illinois University at Carbondale
Computing Affairs
Computer Learning Center 1, Faner 1027
Carbondale, IL  62901
[phone]

------------------------------

Date:    22 Nov 89 09:33:51 +0000
From:    [e-mail] (Bradford Rice Wetmore)
Subject: Virus Attributes Listing

Hi,
I am just getting back into the virus game, and there are quite a few
new ones (and variations).  Is there a quick overview someone has
put together listing some of the common viruses (attributes,
methods of attack, etc.)?  If there was something posted earlier,
I would sure appreciate it if someone could send me a copy.

Thanks much,
Brad Wetmore
Grad Student-UC Davis

No funky signatures, just this:  [e-mail]

------------------------------

Date:    Wed, 22 Nov 89 11:19:03 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Any volunteers ? (PC)

For the past four months I have been working on a comprehensive
anti-virus package, capable of detecting/stopping and removing all PC
viruses known.

Well, it is finally finished.

The package will be posted on comp.sys.ibm.pc and made available on
SIMTEL and various anti-virus archives.

Right now I am looking for a few volunteers. The package itself has
been thoroughly tested (I estimate that it is running on 5-6% of the
computers here in Iceland), but I need a bit of help with....

          ... checking that the programs do indeed disinfect all infected
          programs and diskettes. I have verified that it will "cure"
          all the samples I have of the following viruses:

                 Alameda (Yale)
                 Brain
                 Den Zuk/Ohio
                 New-Zealand (Stoned)
                 Pentagon
                 Ping-Pong/Typo
                 Swap (Israeli Boot)
         Alabama
                 April 1.
                 Cascade
                 Dark Avenger
                 DataCrime
         DataCrime II
         dBase
         Do-Nothing
                 405
         Fumble
                 Fu Manchu
         Ghost
                 Icelandic/Icelandic II/Saratoga/Mix1
                 Jerusalem/Sunday
                 Lehigh
                 South African "Friday 13."
                 SysLock
                 Traceback/2930
         Vacsina
                 Vienna/Lisbon
         Yankee Doodle
         Zero Bug

             but there may be variants floating around that I do not have a
         copy of. If you have a collection of viruses, I would appreciate
         if you could test this.

    ...  Another problem is the manual. It consists of several text files,
         around 65K in size. Since English is not my primary language,
         (and not even my second language, for that matter), I am sure
         there are some serious spelling and grammar errors in the
         documentation. Anybody willing to take a look at that ?

- -frisk

------------------------------

Date:    Wed, 22 Nov 89 12:19:35 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: High Level Language viruses

Most of the viruses we have seen to date seem to be written in
assembly language. However, it is possible to write viruses in a High
Level Language (HLL), and a few such viruses have been reported. The
AIDS virus, written in TURBO Pascal is probably the best known one.

Compared to an assembly language virus, a HLL virus will have the following
"features":

    * It is bigger. The AIDS virus, for example, is around 12K,
      which makes it the biggest virus known.

    * It is more difficult to select good signature strings, since
      most of the code produced by the compiler is probably also
      present in a number of other (legitimate) programs. This makes
      the job of detecting HLL viruses a bit harder.

    * Is is much harder to write a good .EXE file infector in Pascal
      or C than a .COM infector.

    * Just about any programmer could write an usable .COM infector in
      C or Pascal in less than an hour. (I mention C and Pascal because
      they are the most popular languages, but a virus could just as
      easily be written in other languages, Forth, Basic or even APL
      or Cobol. Can anybody imagine what a Cobol or APL virus would
      look like...    ;-)

Comments ...?

- -frisk

------------------------------

Date:    Tue, 21 Nov 89 18:41:50 +0200
From:    Y. Radai <[e-mail]>
Subject: Corrections and new details on DataCrime (PC)

  Last month I wrote that whereas the original DataCrime virus per-
forms its damage from Oct 13 to Dec 31, DataCrime II does it from Jan
1 to Oct 12.  David Chess and Alan Solomon both replied that in their
copies of DC II, the dates were the same as for DC I: Oct 13 - Dec 31.
That left two possibilities: either there's a mutation with the date
range modified, or my sources were mistaken.
  One source for the Jan 1 - Oct 12 range was the July/August issue of
the Computer Security Newsletter.  I did not at the time accept this
as necessarily correct.  But when I saw a similar statement in the Sep
issue of the Virus Bulletin by Joe Hirst, who does independent disas-
semblies and who always seemed very accurate and reliable in the past,
I became convinced that this was correct.
  After the differences of opinion, however, Joe admitted that he had
been mistaken and that the date range for DC II was the same as for DC
I even on his copy.  Since there apparently haven't been any further
claims for the pre-Oct 12 dates, I tend to believe that the CSN was
also mistaken.  Of course, one *could* easily modify DC II to activate
on Jan 1 - Oct 12 (or on any other date range), but it makes more
sense for the infection period to be long than for the damage period
to be long.
  Joe also wrote originally that Sundays are excluded from damage by
DC II.  This also turned out to be incorrect, although in this case
the correct behavior is different than for DC I: Mondays are excluded.
Following is the relevant part of the code for each virus (I have
translated the disassembly into a pseudo high-level language; the
variable Hdflag contains 0 if there is no hard disk, 1 if there is):

             DataCrime I
  If current date > Oct 12 then go to Hard-disk test;
  Go to Infection routine;
Hard-disk test:
  If Hdflag not 0 then go to Damage routine;

             DataCrime II
  If current date > Oct 12 then go to Day-of-week test;
  Go to infection routine;
Day-of-week test:
  If day-of-week (0 for Sunday, 1 for Monday, etc.) not = Hdflag
         then go to Hard-disk test;
  Go to Infection routine;
Hard-disk test:
  If Hdflag not 0 then go to Damage routine;

Thus in DC II the damage will be performed only if there is a hard
disk and the date is after Oct 12 *and the day is not a Monday*.

  To summarize, there are (at least) six differences between DC I and
DC II:
                               DataCrime I       DataCrime II
Type of files infected:        COM               COM/EXE
Size increase:                 1168 or 1280      1514
Days excluded from damage:     None              Mondays
Encrypted?                     No                Yes
Files excluded from infection: 7th letter = D    2nd letter = B
Message:                       DATACRIME VIRUS   DATACRIME II VIRUS

  So much for corrections.  Now for some new info on these viruses.
Both of them contain code which low-level formats Track 0 on all heads
from 0 to 8.  The pseudo-code looks like this:

  H := 0;
Loop:
  Format Track 0, Head H;
  If error go to Continue;
  H := H+1;
  If H not = 9 then go to Loop;
Continue:

But what happens in the case of disks having less than 9 heads?  Pre-
viously, it was assumed by many that this would result in an error, so
that the extra heads would be ignored, i.e. the virus would format
only Cylinder 0.  But Joe has discovered by experimentation that in
most cases the number of tracks formatted is actually 9, even if this
goes beyond Cylinder 0.  The explanation is that most BIOSes convert
an invalid head number into the valid equivalent. On a 17-sector/track
disk, this will wipe out 153 sectors, which on most hard disks contain
the partition record, boot sector, both copies of the FAT, the root
directory, and possibly some files.

  Fridrik Skulason reported in Virus-L that he was able to recover
from an attack of DC II by using the Norton Disk Doctor.  This might
seem to contradict the above findings.  However, he rebooted before
the virus had a chance to format very much of the disk.  It seems
likely that if he had not done this, all of Norton's horses wouldn't
have been able to put his disk together again.

  There is a package available from Simtel20, called COLUMBUS, which
is supposed to be of use against the "Columbus Day" [i.e. DC] virus.
It consists of two simple programs, ST0 and RT0.  ST0 saves the con-
tent of a certain portion of the hard disk on a diskette file, and RT0
restores it in case of damage by the virus.  Just which portion is
saved is not very clear from the documentation.  In one place it says
"Track 0", while in another place it says "cylinder zero".  Experiment
shows that ST0 saves Track 0 on Head 0 only, which is of little use
against the DC viruses.  A look at the source code shows that the
author left the possibility of saving all of Cylinder 0 by defining a
certain symbol at compile time, but as we now know, even that isn't
enough.  However, the source code can presumably be modified to save
all 9 tracks damaged by a DC virus by simply replacing "maxhead=0" by
"maxhead=8" in both ST0.C and RT0.C.

  Joe Hirst has written a small resident program to prevent damage by
the DC viruses, or more generally, to halt any program which attempts
to low-level format any part of a hard disk by a call to Int 13h func-
tions 5-7.  It (along with the above clarifications on the extent and
dates of the damage) appears in the Nov issue of the Virus Bulletin.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

Date:    Wed, 22 Nov 89 08:30:02 -0500
From:    [e-mail] (Jason D. Blue)
Subject: RE: Potential Virus? (Mac)

In VIRUS-L V2 #246, Joel Glickman writes:

>I have just recently noticed a problem on my Mac. After using Cricket
>Graph I checked the last modified date and the program had just been
>modified.  After noting this, I began checking other programs and
>found that my copy of Versaterm Pro was also being modified every time
>I ran it. It was at that point that I checked these programs on other
>people's Macs in the office and saw that these programs were not being
>modified on some, while they were being modified on others.. I am
>running Gatekeeper and Vaccine and have checked these programs with
>Disinfectant and they report no trouble.

I have noticed the same problem, with a number of applications (among
them are TinCan and Mac286).  I use SAM Intercept from Symantec, and
it alerts me from time to time that an application is trying to change
itself.  I checked for viruses, using a number of packages (Virex,
Sam, Disinfectant and Virus detective), but found none.

I don't think this is a virus, but I find it disturbing because, like
Joel mentions, this happens even when I only start an application and
then quit out of it, without changing preferences or options that
might need to be saved to disk.
Jason
                                    User Services
/~~~ Jason D. Blue                The MITRE Corporation
|o|o|  [phone]               7525 Colshire Drive MS W130
v_/  [e-mail]          McLean, VA 22102-3481

------------------------------

Date:    Wed, 22 Nov 89 09:30:00 -0500
From:    I Like Hike! <[e-mail]>
Subject: Self-modifying applications (Mac)

In issue #246, Joel Glickman writes...

>From:    [e-mail]
>Subject: Potential Virus? (Mac)
>I have just recently noticed a problem on my Mac. After using Cricket
>Graph I checked the last modified date and the program had just been
>modified.  After noting this, I began checking other programs and
>found that my copy of Versaterm Pro was also being modified every time
>I ran it. It was at that point that I checked these programs on other
>people's Macs in the office and saw that these programs were not being
>modified on some, while they were being modified on others.. I am
>running Gatekeeper and Vaccine and have checked these programs with
>Disinfectant and they report no trouble.
>My question is: Should these programs modify themselves when I just
>run them.  All I do is run them and quit immediately and they are
>modified??? Do you think I have a virus problem???
>Joel Glickman
>Rensselaer Polytechnic Institute.

Some programs DO modify themselves while running, the important thing
to remember is that these modifications are usually made to the data
fork of the application.  Most virus detectors look only for attempts
to write to resource forks.  (I don't know about Gatekeeper, perhaps
its author could let us know?)  It still seems strange that other
people were not experiencing the same problems as you, but that
doesn't necessarily mean a virus.  To quote Douglas Adams "DON'T
PANIC", as many others do.  Here are some things you can check:

        1.      The other people you are working with may have locked their
                copies of CG or Versaterm Pro, preventing them from being
                modified.

        2.      Make sure Vaccine is running, look in your control panel and
                see that the protection is turned on (incidentally, when you
                alter the preferences for Vaccine, the size of the file
                changes, since Vaccine has no "preferences" file)

        3.      Try replacing your cricket graph with someone else's, see if
                the problem persists.  Likewise for Pro.

        4.      Try reinstalling your system, use the same release as those
                coworkers of yours who are not experiencing this phenomenon,
                again, see if the problem persists.

        These are just ideas, they're not carved in stone, but they may
provide some insights...  good luck!

                                        -- Chuck Seggelin
                                           Academic Computing Services
                                           SMU
[e-mail]           "Opinions expressed are MINE alone!!!!"

------------------------------

Date:    22 Nov 89 15:11:04 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Internet worm impact (UNIX & Internet)

We'll never have exact figures, of course.  Here are some ballpack
figures that represent my estimates based on site accounts from over
100 sites, plus some additional information I've gathered elsewhere.

I believe that between 3000 and 6000 machines were infected by the
virus, at perhaps 500 sites maximum.

Many more 1000s of machine were affected by network disruption or
preventative action, however, but those machines were not
directly infected.


Many of these machines were "down" for only 6 to 12 hours.  Few of the
infected machines are used 24 hours per day, so most were not
discovered to be infected until Thursday morning. Within 24 hours of
the infection starting, folks at Berkeley had distributed source code
patches to stop its spread, and folks at Purdue had developed and
publicized an innoculation that would prevent infection.  Thus, most
machines were affected for less than a single business day.

Most admins discovered early on that rebooting all their machines at
once cleared them of the Worm.  Once this occurred, reinfection from
outside often failed to happen -- other machines were also being
cleared, and bugs (probably) in the Worm code caused it to spread more
slowly than many people think it did.  The massive infection that
occurred happened only because it had overnight on lightly-loaded
machines to probe across the net.  Once sites started to go down and
disconnect, the rate of infection dropped significantly.

A very large percentage of the infected machines were single-use Sun
workstations, or small Vaxen.  Thus, the number of users prevented
access was much less than the 20 people per machine quoted in one of
the preceding articles.  3-5 per machine might be better averages.

Many of the affected users were students.  Their time can hardly be
valued at $27 per hour.  On the other hand, many machines belonged to
faculty or research engineers.  Their time is usually valued a bit
more than $27 per hour.

Lost time is very difficult to value.  I'd guess that based on
everything I've heard and the information I've gathered, I'd estimate
the "loss" as between $30million and $50million.  McAfee's estimate of
$96million was, at best, badly estimated, and at worst self-serving
and irresponsible.  Numbers greater than $75million cannot be
supported in the face of critical analysis.

5% of the machines on a known-to-be-insecure network of loosely
administered machines were infected.  This is noteworthy, but it
was not the crisis some people have claimed it to be.
- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 27 Nov 1989    Volume 2 : Issue 248

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

"Where Did They Come From"
Potential impact of internet worm
Anti-virus industry research
Re: high-level language viruses
fPRT is **not** a virus (Mac)
Stoned Virus Killer (PC)
"Viruses" that mutate...
Non-executable viruses
Re: 80386 and viruses (PC and UNIX)
Re: Known PC Virus List (PC)
New virus: "Jude" (Mac)
EAGLE.EXE 2nd Version Discovered (PC)
DIR EXEC on VM (VM/CMS)
EAGLE.EXE 2nd Version Discovered (PC)
DIR EXEC on VM (VM/CMS)
Re: Using Relay for real time conference (BITNET)
The DIR EXEC consequences... (VM/CMS)

---------------------------------------------------------------------------

Date:    Wed, 22 Nov 89 11:05:00 -0500
From:    [e-mail]
Subject: "Where Did They Come From"

Thanks to Fridrik Skulason for his contribution.

It sustains my intuitive observation that Israel's merely two million
people are disproportionately represented as sources.  Perhaps they have
too much time on their hands.  Perhaps someone there fails to realize
his own interest in an orderly sandbox.

While we have been totally ineffective, not to say inept, in identifying
virus authors, there would seem to be an advantage to starting in a
small population with a lot of clues.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Wed, 22 Nov 89 12:44:00 -0500
From:    [e-mail]
Subject: Potential impact of internet worm

Gene Spafford notes that the Morris worm (I still prefer to call it a
virus; afterall, it DID use the machinery of what it was infecting to
propagate itself) only infected 5% of the machines on a
known-to-be-insecure net.  It was stopped because it was noticed.  It
was noticed because of bugs that made it replicate much faster than
was intended.  Has anyone estimated how far it would have gotten had
those bugs not been there, i.e., if it had replicated so slowly as not
to be noticed?

------------------------------

Date:    Wed, 22 Nov 89 13:35:00 -0400
From:    [e-mail]
Subject: Anti-virus industry research

I am an MBA student at the Wharton School, U. of Pennsylvania
researching the anti-virus software industry for a course in
entrepreneurial management.  I would greatly appreciate a list of
*comercial* anti-viral packages with a basic description of what they
do (detection, removal, etc.) and the addresses and/or telephone #s of
their publishers.  Since the field keeps changing so quickly (that's
why I'm studying it) it's very difficult for those of us not involved
directly with the industry to keep abreast.

Please send any info, comments or observations on the industry to:

[e-mail]

Thanks very much in advance and best regards from:

Ethan M. Rasiel
Wharton School, U. of PA
Philadelphia, PA

------------------------------

Date:    Wed, 22 Nov 89 14:19:43 -0500
From:    [e-mail] (David Gursky)
Subject: Re: high-level language viruses

In Virus-L V2 #247, Fridrick Skulason ([e-mail]) asks
about viruses written in higher-level languages.

An oft ignored fact of HLL viruses is that some do have the ability to
spread between machines running the same HLL.  For example,
Smalltalk-80 operates on Macs, PS/2s, and 286 based PCs.  Now suppose
I write a virus that is written in Smalltalk-80.  It will not infect,
say, the System file on a Mac, or the .COM files on PCs, but it could
spread from Smalltalk-80 Mac to Smalltalk-80 286.

A precursor to this was the Dukakis Virus of last year.  The Dukakis
virus was written in Hyperscript, the programming language behind
Apple written in Hyperscript, the programming language behind Apple's
Hypercard product.  We are seeing Hypercard compatible products for
MS-DOS (Spinnaker's Plus product for the Mac and PC -- See MacWeek
21-Nov).  Consequently, Dukakis type viruses could pose threats to
both Macs and PCs, although only to a subgroup of those platforms
(those running the infectable application).

------------------------------

Date:    Thu, 23 Nov 89 22:02:58 +0000
From:    biar![e-mail] (Robert J Woodhead)
Subject: fPRT is **not** a virus (Mac)

Reports are flying around a variety of networks concerning an alleged
virus that leaves a "fPRT 0" resource in the Finder and other files.

fPRT 0 is created by the finder (and some other programs) when the
user changes the default print settings with "Page Setup..."  It is
not evidence of a virus.  The resource is about 120 bytes long and
does not contain code.  In any case, absent some other mechanism, it
could never be executed anyway.

While there may be some new virus out there (odds favor there not being
one, if my experience is any guide), fPRT 0 has nothing to do with it.

Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    24 Nov 89 00:40:41 +0000
From:    [e-mail]
Subject: Stoned Virus Killer (PC)

I have seen a couple of postings asking about programs for zapping the
'Stoned' virus. There is one called KILLER written by someone at
Victoria University in NZ that removes the virus and restores the old
boot sector (I believe). I checked on the SIMTEL20 archives and it
doesn't seem to be there so don't know if it is easily obtainable
outside of NZ. I can post it to this group or get it put somewhere
accessible if this is the case.

#############################################################################
#       \|||/        Michael Jones             Phone: +64 +63 69099 Ext 7816#
#       /   \        Computer Science Dept     Fax:    [phone]           #
#      / O O \       Massey University         E-mail: [e-mail] #
# =000====U====000=  Palmerston North, NZ                                   #
#############################################################################

------------------------------

Date:    Wed, 22 Nov 89 16:11:12 -0500
From:    [e-mail] (John McMahon)
Subject: "Viruses" that mutate...

***> From:    Peter Zukoski <[e-mail]>
***> Subject: followup on mind viruses
***>
***> Dear virus-folk: thanks for all the responses to Richard Dawkins
***> questions. Here's some further thoughts from Richard on the topic of
***> mind viruses...He and I would be interested in your opinions, especially
***> on evolving/mutating virus technology. Has anyone seen viri which
***> evolve, or mutate in response to the environment which it is in? Or viri
***> which recognize and "use" other viri which might be present?

The recent attacks by the WANK worm on the "World DECnet" was an example
of a program that "evolved" and "mutated" as it propagated through the
network.

It "evolved" such that it added to itself when it learned a new common
username to attack.  Each new common username added an additional line
to the code, thus making the worm a little bit "smarter".

It "mutated" such that the program would delete certain routines if the
program determined that certain conditions applied.  These conditions
were related to it's discovery on the network.

Admittably, these are simple examples.  But they may be an indication of
things to come.

/------------------------------------+----------------------------------------\
|John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)   |
|Advanced Data Flow Technology Office|Internet: [e-mail] |
|Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT               |
|NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                      |
|Greenbelt, Maryland 20771           |   Phone: [phone] (FTS: 888-2045)  |
+------------------------------------+----------------------------------------+
|X.400 Telenet Mail:   (C:USA,ADMD:TELEMAIL,PRMD:GSFC,O:GSFCMAIL,UN:JMCMAHON) |
|GSFC XNS (3+Mail):             {[e-mail]}:INTERNET:GSFC |
+-----------------------------------------------------------------------------+
|"Living a 9600 Baud Lifestyle in a 1200 Baud World" - R.A.J.                 |
\-----------------------------------------------------------------------------/

------------------------------

Date:    Wed, 22 Nov 89 01:52:21 -0800
From:    John Goodman <stanton![e-mail]>
Subject: Non-executable viruses

I am puzzled by something.

Last summer I recall seeing an article about a virus that infected
spreadsheets.  That's right, spreadsheets, not spreadsheet programs.
(Sorry, I don't recall either the author's name or the name of the
article.  I was given a copy, so I am unsure where or even if it was
printed for wide distribution.)

The described virus's method of action was an auto-executing macro
that was hidden somewhere in a large spreadsheet where it was unlikely
to be noticed, yet whenever the spreadsheet was loaded it would "do
its thing."  Since, this author asserted, modern spreadsheet programs
often have very powerful macro languages including access to DOS
functions and running DOS programs and an auto-execute feature, it is
possible to write a comparably powerful virus in this fashion.

Naturally, such a virus would not be found by looking only at .EXE and
.COM files (plus the boot sector).  It could only be found by looking
inside the worksheets and knowing something of the nature of their
storage of that kind of macro (a knowledge that would vary by the
brand and release of the various spreadsheet program on the market).

What puzzles me is that this author said he had withheld saying
anything about his ideas along this line until he had actually seen a
live sample of such a virus.  Then he did experiments in his lab to
confirm his notion of what was going on, then wrote it all up in the
paper I saw.

I have seen nothing here about this problem, nor do the VIRUSCAN
programs look for any such viruses.

Has anyone here seen such a virus?

Are there any programs that do check for such?

Is there anyone concerned about this (potential or actual ??) problem?

I also note that a similar virus problem could manifest with bogus
code being included in any source file that would be "run" through an
interpreter on any computer system (which includes a lot of games in
interpreted BASIC, often distributed in a fashion that makes it at
least very difficult to list their contents), so we are not really
only talking here about spreadsheets and PCs.

I am not sounding an alert, as I have not seen any such virus myself.
I am instead voicing a concern and asking for references to any
programs that might help one protect one's computer(s) (PC systems in
particular) against that sort of threat.

- -----------------------------------------------------------------------------
John M. Goodman, Ph.D.
GOOD CODE WORKS
P. O. Box 746, Westminster, CA 92684-0746         [phone] (voice)
uucp:   ...!lll-winken.llnl.gov!spsd!stanton!john
- -----------------------------------------------------------------------------

------------------------------

Date:    Wed, 22 Nov 89 13:02:18 -0600
From:    Peter da Silva <[e-mail]>
Subject: Re: 80386 and viruses (PC and UNIX)

In article <[e-mail]> you write:
> [e-mail] (Peter da Silva) writes...
> >It's called "Merge 386" or "Vp/IX".

> >[Ed. These products, by the way, are DOS emulation boxes for i386
> >based UNIX and XENIX products.]

> Would someone elaborate on this?  Surely a program (virus or otherwise)
> running under the emulator could do the same things, including deleting all
> the files it can find, as on DOS.  What protection is provided?

DOS runs as a UNIX task subject to the UNIX protection mechanisms. In
particular, it does not have direct access to the hardware unless
deliberately configured that way, and it does not have permission
to write any files that a normal UNIX task could not write. There is
also no backdoor to the file system via any BIOS.

So it's not subject to infection by standard DOS virus techniques, and
even if the DOS emulator becomes infected the damage would be limited
to the DOS-accesible files in a single user's account.

It's also not possible to directly read or write the configuration files
from DOS, because they're owned by the superuser and protected from
writing.

Now it should be possible to write a virus that would deliberately infect
DOS under UNIX systems (by setting up a trojan horse, for example), but
this would be a second-level effect... and the number of such systems
is much smaller than pure-DOS systems (a 386 box costs something like
5 times an XT) that it's not a very tempting target.

`-_-' Peter da Silva <[e-mail]> <[e-mail]>.
 'U`  --------------  [phone].
"The basic notion underlying USENET is the flame."
    -- Chuq Von Rospach, [e-mail]

------------------------------

Date:    23 Nov 89 09:40:02 +0000
From:    [e-mail] (G. Nijenhuis)
Subject: Re: Known PC Virus List (PC)

[e-mail] (David.M..Chess) writes:
>Quite welcome for the format, and thanks for the acknowledgement!
>
>Nice list!

Was there a complete Virus list posted to this group ?

If so, I missed it. We had some troubles with the net news over here
and missed a lot. I am very interested in this list, so would somebody
please be so kind to send it (or post it) to me ?

Many thanks in advance.

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
# Gerrit Nijenhuis                 Internet :  [e-mail]  #
# Philips TDS, Dept. SSP           UUCP     :  ...!mcvax!philapd!nyenhuis    #
# Apeldoorn, The Netherlands       Phone    :  [phone]                 #

------------------------------

Date:    24 Nov 89 15:10:09 +0100
From:    Markus Mueller <[e-mail]>
Subject: New virus: "Jude" (Mac)

A new variant of the nVir virus has shown up here at ETH, Zurich,
Switzerland.  Infected applications show a "CODE" 256 and various
"Jude" resources.  VirusDetective 3.1 does detect the virus while
Disinfectant 1.2 does not.

More details will follow.

   Markus Mueller
   Communications Systems Group
   Eidgenoessische Technische Hochschule
   CH-8092 Zurich
   Switzerland

   Switch : [e-mail]
   ARPA   : [e-mail]
   UUCP   : [e-mail]
   X.400  : G=markus;S=mueller;OU=inf;O=ethz;P=ethz;A=arcom;C=ch

------------------------------

Date:    Sun, 26 Nov 89 09:46:00 -0500
From:    IA88000 <[e-mail]>
Subject: EAGLE.EXE 2nd Version Discovered (PC)

Samples of a second version of EAGLE.EXE have been received from both
Washington and Wichita during the past several days. These are similar
to the original EAGLE.EXE file with one main difference. These new
copies contain a modified form of the AIDS virus.

As per the first version, SCAN.EXE will not detect the virus in this
new version of EAGLE.EXE.

Please see VIRUS-L for a more thorough follow up.

------------------------------

Date:    Sun, 26 Nov 89 16:11:56 -0500
From:    Carsten Zimmer <[e-mail]>
Subject: DIR EXEC on VM (VM/CMS)

last night I received an EXEC named 'DIR EXEC' which proposed only do
list CMS-files in a MSDOS convenient format. It does it, ok, but in
addition it also sends itself to all entries in your NAMES and NETLOG file.

It's the sam story as with CHRISTMAS EXEC which last year clittered up the
networks.

    regards, Carsten

------------------------------

Date:    Sun, 26 Nov 89 09:46:00 -0500
From:    IA88000 <[e-mail]>
Subject: EAGLE.EXE 2nd Version Discovered (PC)

 I should have know better than to think my last report was the final
report on this subject. Over the past several days a NEW version of
EAGLE.EXE was discovered in Washington and Wichita.

 This new version contains the same "trojan", ie; if COMMAND.COM is
found in the ROOT directory, AND if the system has a '286, '386, or
'486 CPU, EAGLE.EXE will proceed to overwrite the Boot sector and
both FAT's as well as several other sectors with an ASCII 246.

 The major difference is that the new version of EAGLE.EXE has a
new strain of the AIDS virus, which is alive, well and infectious.

 EAGLE.EXE was again compressed, which stops "SCAN.EXE" from
recognizing the virus contained in the file.

 Here is all we know about the two versions of EAGLE.EXE:

 EAGLE.EXE - Version 1 contains the Jerusalem B virus and a very
nasty trojan which will check for COMMAND.COM in the root and if
it is found and if the CPU is a '286 or higher, EAGLE.EXE Ver. 1
will overwrite the Boot sector and both FAT's with ASCII 246.

EAGLE.EXE - Version 2 - Same as above except it contains a new
strain of the AIDS virus.

 Both programs were written in Quick Basic and compiled using BASCOM.

 Both programs are compiled and compressed in such a way as to prevent
a normal scanning utility from detecting the viruses in these files.

 A floppy disk can be protected from the trojan by a write protect tab.

 Both of the viruses are currently active. The trojan part of each
IS NOT part of the virus.

Now for the good news:

EAGLSCAN which was made available by the people at SWE has been
modified to detect both versions of EAGLE.EXE and is currently
being made available to VIRUS-L readers, FREE of CHARGE, by simply
sending a formatted 5.25 inch 360k disk with a return address label
and RETURN POSTAGE (stamps ok) to the following address:

                             SWE
                             132 Heathcote Road
                             Elmont, New York 11003

You will receive the latest version of EAGLSCAN, which can detect and
warn you if either version of EAGLE.EXE is present. There is no charge
for the program, but PLEASE....include postage (stamps ok)! The people
at SWE have gone out of their way to help in this matter and it is
only fair to include postage. Of the three hundred requests received so
far, twenty three of them did not include return postage. SWE has
decided to return these disks, via Parcel Post, so those who did not
send postage will receive the program, as soon as the US Mail service
gets around to delivering their Parcel Post shipments.

In answer to some of the people who have sent mail, neither version of
EAGLE.EXE will be available or uploaded to Homebase. The announcement
that it would be made available to McAfee Associates was premature to
say the least. I am not privy to why this decision was made.

It would appear your ONLY source for a program which can detect either
version of EAGLE.EXE is the above address. The latest version of SCAN
from McAfee was tested again on both versions of EAGLE.EXE and was not
able to detect a virus in either file.

To those who already sent disks to SWE, I have been informed that every
disk sent, (except for the ones without postage) is now on its way back
to you, via US mail. SWE finished up the disks early this AM and all
were deposited with the US mail service.

If you desire to receive a free copy of EAGLSCAN, please be sure your
formatted disk, return disk mailer and return postage (stamps ok)
arrive at SWE, NO LATER than December 15th. SWE will be closing for the
holidays December 18th, and will process all disks received as of 12/15.

Thanks must be passed along to the two people in Washington and Kansas
who sent the new versions of EAGLE.EXE for examination.

That is about it for now.

------------------------------

Date:    Sun, 26 Nov 89 10:56:21 -0500
From:    Doug Sewell <[e-mail]>
Subject: DIR EXEC on VM (VM/CMS)

This was just posted on LSTSRV-L and several other groups - Doug
- ---
>Date:         Sat, 25 Nov 89 19:15:31 EDT
>Sender:       Revised LISTSERV forum <LSTSRV-L@RUTVM1>
>From:         "Juan M. Courcoul" <[e-mail]>
>Subject:      IMPORTANT WARNING: CHRISTMA workalike on the loose on the links
>
>This is an emergency warning. As such it has been sent to several important
>lists; please excuse the multiple cross-posting.
>
>A dangerous REXX exec named DIR EXEC has been detected on our node, thanks
>to a watchful recipient. This exec purports to be able produce a directory
>listing of the user's disks in a MS/DOS (PC) format.
>
>However, when the exec is run, it will produce the promised listing BUT it
>will also send a copy of itself to all net addresses found in the user's
>NAMES and NETLOG files.
>
>This will, of course, swamp the BITNET network in a very short time if it
>is allowed to run unchecked. Its behavior is, damagewise, identical to the
>CHRISTMA EXEC which attacked both BITNET and VNET (IBM's corporate net)
>approximately three years ago.
>
>All system operators, postmasters and people in charge: if you find the DIR
>EXEC in your system's RDR queue, flush immediately. The copy we detected has
>the following characteristics:
>
>FILENAME FILETYPE FM FORMAT LRECL       RECS     BLOCKS
>DIR      EXEC     B1 V        116        167          1
>
>The datestamp is not a reliable indicator; in two different copies found in
>our RDR queue, the date was different.
>
>Also, please post warnings on your systems, alerting your users about this
>problem.
>
>Thanks for your immediate attention to this urgent problem.
>
>Juan
>
>/-----------------------------------------------------------------------\
>  Juan M. Courcoul                  | Phone: [phone]  Ext. 4151
>  Postmaster / Listserv Coordinator |
>  Dept. of Academic Services        | Net: [e-mail]
>  Monterrey Campus                  |      [e-mail]
>  Monterrey Institute of Technology |      [e-mail]
>  Monterrey, N. L., Mexico  64849   |      [e-mail]
>\-----------------------------------------------------------------------/

------------------------------

Date:    Sun, 26 Nov 89 15:08:58 -0500
From:    Jon Allen Boone <[e-mail]>
Subject: Re: Using Relay for real time conference (BITNET)

I think using RELAY as a method of talking about viruses would be
great.  How about setting up a time?  Like, say a weekly or bi-weekly
meeting?  that way everyone would be welcome, and such.

Also, does anyone have any information on any books or papers written
about viruses?  You know, sort of like a beginner's guide to viruses.


------------------------------

Date:    Sun, 26 Nov 89 12:45:28 -0800
From:    Pseudo Dragon <[e-mail]>
Subject: The DIR EXEC consequences... (VM/CMS)

It seems to me that the latest DIR EXEC has become far more publicized than
The author could have possibly hoped for.
Due to the multiple-list posting, the warning message got bounced around
sixteen times or so from [e-mail] ...
Thus jamming Bitnet far more effectively than the DIR EXEC ever could.
Perhaps this was the desired effect the author wanted?
 ------------------------------------------
>From the desktop computer of: Charles Howes, [e-mail]
  "Clothes make the man; Naked people have little or no influence in society."
    -- Mark Twain

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 28 Nov 1989    Volume 2 : Issue 249

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Sophisticated Viruses (Mac)
seeking Gatekeeper (Mac)
'Tis the season
2600 VAX Virus (VMS) ?
Re: 80386 and viruses (PC & UNIX)
Re: Potential Virus? (Mac)
More on Signature Progs
More on the DIR.EXEC problem
EAGLE.EXE Trojan (PC)
Possible DIR EXEC Remedy (VM/CMS)
Questioning Netscan (PC - Novell)
Re: DIR EXEC (VM/CMS)
DIR EXEC revisited... (VM/CMS)
Linkable virus modules
stoned virus in partition table
Traceback (PC)
Re: Where did they come from ? (PC)
Re: Non-executable viruses
Eddie ? (PC)

---------------------------------------------------------------------------

Date:    Sun, 26 Nov 89 17:03:22 +0100
From:    [e-mail]
Subject: Re: Sophisticated Viruses (Mac)

[e-mail] (Chris Johnson) writes:

>There would be crashes because it's very common for software that
>patches traps to have interdependencies between its patches, i.e. one
>patch depends on data discovered and stored for later use by another
>patch.  Removing only a portion of such patches will be likely to kill
>the machine sooner or later.
> . . .
>Further, restoring traps to their original values is going to remove
>all of the patches put in place by the System itself - the patches
>that keep that machine running inspite of bugs in the ROMs, etc.
>Also, whole portions of the OS and Toolbox will be removed by
>restoring traps to their initial values (as taken from the ROM) - this
>will kill the machine for sure.
> . . .

So what if I remove system patches? You seem to think that I need to
call every little routine in ROM to do my dirty stuff. What I need is
say, ChangedResource, WriteResource and perhaps AddResource. What do
these traps have to do with OS traps? How many system patches are
there for these traps?  Do you *really* think that the ROM is truly
and utterly worthless without the system patches? Do you think they
wrote routines that didn't work at all and then patched them into
working? Why would I care if there is some small and obscure bug in
the ROM that could make my virus crash with prob. .000001%, after all
that is probably the whole idea with the virus after all!!

I don't claim that the ROM is bug free, but your indirect claim that
every trap is buggy is pretty heavy. (I got that from the "fact" that
everything will kill the machine "for sure", in case you wonder).

> . . .
>Writing well behaved patches is a black art on the best of days -
>writing the sort of un-patching patches discussed here would make that
>"black art" look like a carefree romp in the sunlit countryside.  I
>don't think such patches could be implemented safely, and I don't
>think anyone clever enough to do so would be wasting his time working
>on viruses in the first place.

This proves you've missed the point entirely. We're not talking about well
behaved viruses here. And just because you think no one would write one isn't
exactly proof that no one will...

>All in all, I don't think the techniques dealt with in this discussion
>are significant simply because there are too many reliability and
>compatibility problems intrinsically linked to them.

I do think they are significant though. The whole point with my post in the
first place was to make people realize that a virus could bypass the
protective fences of all anti-viral programs (including Gatekeeper) pretty
easily (theoretically anyway). What if a virus changed the resource map
directly without going through the ROM at all? We can't just rely on the
trivial and obvious protection that Gatekeeper et al. provies. What we need
is sophisticated protection schemes, and unless there's no discussion of
potential viruses we might never come up with these schemes in time.

>- ----Chris (Johnson)

/Christer

| Christer Ericson                            Internet: [e-mail] |
| Department of Computer Science, University of Umea, S-90187 UMEA, Sweden |
| "Track 0 sector 0 must *always* load into page 8!" -Krakowicz' first law |

------------------------------

Date:    Sun, 26 Nov 89 03:05:08 -0700
From:    Ben Goren <[e-mail]>
Subject: seeking Gatekeeper (Mac)

What's the easiest way to get a copy of Gatekeeper?  I haven't seen
any copies floating around campus here at Arizona State University.

Ben Goren
Bitnet:  AUBXG@ASUACAD

------------------------------

Date:    Mon, 27 Nov 89 08:36:29 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: 'Tis the season (yes 'tis)

This just heard on a local Pittsburgh radio station:

A company is selling a product called 'Safe Disks' (or some such)
which is a floppy disk condom.  The company is marketing it as a gag
gift for the holiday season.

Heavy sigh...

Ken

------------------------------

Date:    Mon, 27 Nov 89 14:56:52 +0000
From:    [e-mail]
Subject: 2600 VAX Virus (VMS) ?

I have just read "The complete Computer Virus Handbook" (issue 1)
written by David Frost.

In it, is described a virus called 2600 VAX virus. Basically a
programm which replicates itself and sends job requests to the batch
queue, which is a list of jobs awaiting execution. The so-called
"virus" caused the queue to overflow...

This was reported in a 1986 edition of the magazine 2600, a hacker
journal.

Well, to me it looks just like a recursive batch program. A two-liner.
We've often had students at our site writing this simple piece of
code, and submitting it to the queue. It surely wastes a lot of paper
(when printing the log files of the program), especially if run at
night, with no operator finding-out that the whole stack of paper
feeding the printer will be printed with garbage !

But does this simple piece of code really need to be mentioned in a
"Virus handbook" ? Did the next issues of this manual still mention
this ?

Olivier Crepin-Leblond, Computer Systems & Electronics,
Electrical & Electronic Eng., King's College London, UK.

------------------------------

Date:    27 Nov 89 19:55:29 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: 80386 and viruses (PC & UNIX)

Actually DOS/MERGE or VPIX is a somewhat cheap way to explore and test
viruses compared with the cost of some other environments that are
supposedly virus proof ... and you get unix to run along with
it!!!what a deal!! actually however you do have to make sure you leave
the permissions pretty much as distributed as peter has pointed out...
if dos programs are allowed to read and write normally(i.e. DOS) then
com and exe infectors can still infect...  int 13 and other
skul-duggery will be disallowed by the dos under *nix environment (you
wont get much in the way of system damage but you can look at the damn
things somewhat safely...I have done some experiments as to the
various possibilities for propagation and they do seem to be minimal
in this environment for general viruses(that does not preclude viruses
written to attack through 386 protected mode anomalys or COFF/*nix
based viruses....(and no I dont want to start a flame war about
whether those are possible or not...I am not speaking theoretically
here...))
    As to the environment its GREAT!!
     cheers
     kelly
                                    Kelly Goen
                                    CSS Inc.

DISCLAIMER: I Dont represent Amdahl Corp or Onsite consulting. Any
statements ,opinions or additional data are solely my opinion and mine
alone...

------------------------------

Date:    27 Nov 89 16:47:56 +0000
From:    oxtrap.oxtrap![e-mail] (Tim Endres)
Subject: Re: Potential Virus? (Mac)

[e-mail] writes:

   My question is: Should these programs modify themselves when I just
   run them.  All I do is run them and quit immediately and they are
   modified??? Do you think I have a virus problem???

   Joel Glickman
   Rensselaer Polytechnic Institute.

Many Macintosh programs modify their resource forks!
All of mine do. If the program saves any "state" for you it is most
likely storing the data in the RF. Rest easy. For now.

------------------------------

Date:    27 Nov 89 16:48:40 -0500
From:    Bob Bosen <[e-mail]>
Subject: More on Signature Progs

My epistle of several days ago regarding ANSI and ISO Message
Authentication Code (digital signature) standards generated quite a
few follow-up responses and other questions. Several people asked me
about my internet address. Most of you guessed correctly. I can get to
internet either via NCSC's "dockmaster" or through CompuServe.
Although CompuServe is more expensive, it is a lot more convenient for
me because I've got a "user-friendly" application for my PC that
automates most of my interaction with CompuServe.

What this means to internet users is that you can send electronic mail
to and receive mail from CompuServe subscribers IF both of the
following conditions are true:

1- You must know the CompuServe account (subscriber) number

2- The CompuServe subscriber must actively access CompuServe and
send/receive mail.

CompuServe subscriber numbers generally look a lot like mine
(71435,1777) and consist of two numeric fields separated by a comma.
In order to convert a CompuServe subscriber number into an internet
address, replace the comma with a period, and append the suffix
"@COMPUSERVE.COM". Thus, when addressing me through CompuServe, my
internet address is:

[e-mail]

A lot of other people sent me mail requesting ways to get hold of the
ANSI and ISO standards I referenced.

Copies of ANSI standard X9.9 can be obtained by sending $2.00 to:

ANSI X9 Secretariat

I am less familiar with ISO than with ANSI. I got my copy of ISO
8731-2 from ANSI because I am a member of the X9E9 working group. But
I believe you can get a copy of ISO standard 8731-2 by writing to:

Steve Wornick commented on the value of sophisticated,
cryptographically based signature programs as follows:

>  Bob Bosen brings up some interesting points, asking why programmers
>  writing authentification (sic) programs are utilizing CRC and
>  checksum algorithms rather than more sophisticated algorithms like
>  ANSI X9.9, ISO 8731-2, or DES. I think it depends on what you are
>  trying to do. If your plan is to encrypt your program and rely on
>  difficulties in decryption for protection against infection,
>  then it probably makes sense to use something very sophisticated,
>  because you want to make certain that no one but yourself can do
>  the decryption....  On the other hand, if you are not encrypting
>  your program but are simply trying to generate a number.... for
>  authentification (sic) purposes, I don't see that it is necessary
>  to use anything more sophisticated than a polynomial. If the virus
>  doesn't know your polynomial, then it's chances of guessing a
>  sequence of characters with which to "pad" your program file in
>  order to generate the same CRC value as the original unaltered
>  program is quite small. Of course, everyone ought to be using a
>  slightly different algorithm (i.e. different polynomials) and
>  ought to be hiding the authentication algorithm.

Industry-standard authentication algorithms such as X9.9 (DES based)
and ISO 8731-2 are NOT intended to encrypt files. They produce a short
"digest" or signature of information (in this case a program file).
Steve's suggestion that CRC algorithms can be sophisticated enough to
make guessing virtually impossible (if the algorithm itself is hidden)
MAY or MAY NOT be true. The risk that this assumption MAY NOT be true
is fairly high, especially if programmers rely on their own resources
on how to write a bunch of different yet "good" CRC algorithms. This
is even more true if the test is "on-line", because on-line
authentication implies on-line presence of the authentication
algorithm, where a sophisticated virus could determine the CRC
algorithm and/or associated initialization vectors (keys).

Today, in late 1989, Steve can make and defend the position that CRC
algorithms are good enough, especially if programmers are
knowledgeable about the security considerations, and if the signature
is calculated and verified "off-line" in environments where no virally
contaminated programs have a chance of grabbing executional control.
But in my opinion, this position is short-sighted. Who can say whether
the more sophisticated viruses of the future will attempt to analyze
CRC signatures or target specific products that rely on CRC methods?
Why not base today's protection on the best available and best
documented facts?  The newly emerging science of authentication
technology has clearly revealed that it is easier to compromise even
sophisticated authentication algorithms than previously thought.

David Paul Hoyt says:

>  Mr. Bosen points to very good documents that will point the serious
>  anti-viral minded software developers to an excellent method of
>  defending their software.... However, I would like to add a comment.
>  Any of these auth-check schemes rely on a small number (1 to n) of
>  of programmed checks to see if the software has been corrupted.
>  While this will defend against a general-purpose or unsophisticated
>  virus, it has little value against a malicious attack against
>  your product.

What kind of "malicious attack against your product" are you talking
about? Whatever it is, I'm sure the other members of the ANSI
standards (X9E9) working group and I would be very interested in
learning about it, because if this assertion is true, it could
possibly compromise the entire banking wire-funds transfer mechanism
that transfers billions of dollars every day. Are you saying you could
write or describe a virus that could infect a program but avoid
detection by an off-line ANSI X9.9-based message authentication code?
I'll acknowledge that this is possible with an on-line ANSI X9.9 MAC,
but it would take a lot of blind luck and something on the order of a
billion guesses. The consensus among standards organizations has been
that this is an acceptable risk in the case of the authentication
algorithms that have been studied and standardized.  As I said in my
earlier message, in my experience both on-line and off-line checks
have advantages and disadvantages, and a sophisticated defense must
allow users to pick and choose from all of these techniques according
to his needs. A heirarchy of interlocking defenses must be put
together, with on-line tests acting as the first line of defense, and
with periodic off-line checks. The on-line checks can detect the
viruses known today, and the off-line checks verify the integrity of
the on-line defenses and also protect against sophisticated future
viruses.

Bob Bosen
Vice President
Enigma Logic Inc.

------------------------------

Date:    Mon, 27 Nov 89 16:47:00 -0500
From:    <[e-mail]>
Subject: More on the DIR.EXEC problem

Apologies if this info on DIR.EXEC has already been posted (I hadn't seen
it before, though).

- --- Forwarded mail from Joachim Lohoff-Werner <C0030006@DBSTU1>

>From [e-mail] Mon Nov 27 16:08:24 1989
Sender: Computer Games List <GAMES-L@BROWNVM>
From: Joachim Lohoff-Werner <[e-mail]>

Hello *.*,

I have also received DIR EXEC and looked into it. After reading the
NAMES and NETLOG files and shipping multiple copies to the people listed
in these files it does something very bad:

The DIR EXEC asks for the system date (QUERY TIME) and erases all files
if the system date is greater then 89, i.e. next year.

Please discard all copies of DIR EXEC in your system RDR queue.

Kind regards, amicales salutations, cordiali saluti, shalom u'bracha,
freundliche Gruesse          Joachim Lohoff-Werner


- --- End of forwarded message from Joachim Lohoff-Werner <C0030006@DBSTU1>

------------------------------

Date:    Mon, 27 Nov 89 12:00:11 -0800
From:    <[e-mail]>
Subject: EAGLE.EXE Trojan (PC)

    The Jerusalem and AIDS viruses reported inside AXE'd files are
similar to dozens of other AXE'd viruses reported on Bulletin Boards
in the past 5 months.  Viruses discovered compressed in such files
have included 1701, 1704, AIDS, Jerusalem (over 20 samples), Vienna,
3066, Alabama, Dark Avenger, Yankee Doodle, Vacsina, Fu Manchu and
Datacrime I.  I'm not sure that developing identifiers for these AXE'd
files is the appropriate thing to do, since there are a virtually
unlimited number of hosts that may be included insidecompressed files.
Also, each version of AXE will produce different strings for the same
executable target.  So far, files like EAGLE.EXE have been treated as
trojans (even though they may contain replicating code) since the
compressed file itself cannot replicate.  Any string that identifies
the virus in the compressed form will not identify it in the free
form, and each virus has an uncountable number of potential compressed
identification strings, since each compressed infected host will be
different.  A thorny problem if we try to tackle it.  I don't believe
we should treat EAGLE any differently than GUNSHIP, BADGIRL or the
dozens of other compressed files that contain previously well known
viruses.
Tim Grant Curry
ICVI BBS Co-ordinator

------------------------------

Date:    Mon, 27 Nov 89 16:18:33 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Possible DIR EXEC Remedy (VM/CMS)

I adapted the following EXEC to help, possibly, in slowing the DIR
EXEC if it is still a problem.  Please note that I am unaware of any
problems with the EXEC, but it has not been what I would call
"extensively tested" (about 30 minutes in the making) so please do not
be upset at me if it does anything really nasty to some files.  It did
not do anything to my files.  (Above should be read "disclaimer".)

 ------------------------Chop Here if you wish--------------------------
/*  This EXEC was written by Karen Maloney and modified by Greg     */
/*  Gilbert to change any files with the filename of DIR and the    */
/*  filetype of EXEC to a new filename and filetype of TROJAN HORSE */
/*                                                                  */
/*  One can place "EXEC ANTIDIR" (quotes included) in one's         */
/*  PROFILE EXEC and have this EXEC executed upon loggin on.        */
/*                                                                  */
/* ------------------------------------------------------------------
  Note: Though we are unaware of any problems with this macro, we don't
  guarantee it in any way whatsoever and we assume
  no responsibility for any damage you may do with it.  ALWAYS HAVE
  BACKUP COPIES OF IMPORTANT FILES!!!!!
                                           - Greg Gilbert -
- -------------------------------------------------------------------- */
/*                                                                   */
"EXECIO * CP (STRING Q RDR ALL"
 if queued() = 1 then exit
 do i = 1 to queued()
 pull . spid . . . . . . . fname type .
 if fname = "DIR" & type  = "EXEC" then
 "CP CHANGE RDR" spid "NAME TROJAN  HORSE"
else nop
end
exit

 ------------------------------And Here---------------------------------

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Mon, 27 Nov 89 15:40:00 -0600
From:    "David D. Grisham" <[e-mail]>
Subject: Questioning Netscan (PC - Novell)

        Has anyone bought and implemented the Novell scanning
program "netscan"?  We (UNM) are purchasing VIRUSCAN for a
few machines, at $15 per this is reasonable.  However, $1000
for a site license of NETSCAN is a bit steep.  We won't buy it
unless it is working at other institutions with great results.
Can you who do, please write me or post?
        I'd also like to hear if anyone can suggest a better
product.  Thanks in advance.
dave

  Dave Grisham, Security Administrator, CIRT      Phone [phone]
  University of New Mexico                        USENET [e-mail]
  Albuquerque, New Mexico  87131                  BITNET DAVE@UNMB

my comment for the day-
     It is to bad that the DOS world can't put out a product like
     Disinfectant (Damn good and free).  Do all the nice guys
     wear Macs?

------------------------------

Date:    Mon, 27 Nov 89 15:56:31 -0500
From:    Arthur Gutowski <[e-mail]>
Subject: Re: DIR EXEC (VM/CMS)

In Virus-L, v2i248, the following warning was posted:

>>Date:         Sat, 25 Nov 89 19:15:31 EDT
>>Sender:       Revised LISTSERV forum <LSTSRV-L@RUTVM1>
>>From:         "Juan M. Courcoul" <[e-mail]>
>>Subject:      IMPORTANT WARNING: CHRISTMA workalike on the loose on the links
...
>>A dangerous REXX exec named DIR EXEC has been detected on our node, thanks
>>to a watchful recipient. This exec purports to be able produce a directory
>>listing of the user's disks in a MS/DOS (PC) format.
>>
>>However, when the exec is run, it will produce the promised listing BUT it
>>will also send a copy of itself to all net addresses found in the user's
>>NAMES and NETLOG files.

From the cross-posting I got from IBM-MAIN@AKRONVM (IBM Mainframe
List), this EXEC also contains a timebomb: if the EXEC is run in 1990,
it will erase all A0 and A1 files from your account's A-disk.

I don't know if this thing has spread as fast as the warnings have,
but it may be worth the added info.

 Arthur J. Gutowski
 Antiviral Group / Tech Support / WSU University Computing Center
 5925 Woodward; Detroit MI  48202; PH#: [phone]
 Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]
=====================================================================
 Disclaimer:  If VM is Virtual Machine, then I'm not really logged on,
              hence, I cannot have sent this message.

------------------------------

Date:    Mon, 27 Nov 89 18:04:00 -0800
From:    Pseudo Dragon <[e-mail]>
Subject: DIR EXEC revisited... (VM/CMS)

Apparently, the DIR EXEC everyone has been receiving is rather nasty.
Not only does it send itself to everyone in the files NAMES and NETLOG,
but also:
>The DIR EXEC asks for the system date (QUERY TIME) and erases all files
>if the system date is greater then 89, i.e. next year.

The advice given was:
>Please discard all copies of DIR EXEC in your system RDR queue.
(Quotes from: Joachim Lohoff-Werner)

I'd recommend editing this EXEC so that the spreading and damage part
is removed *completely*, make it read-only, and use it.  After all, it
*does* perform a useful function!  The only problem lies in getting a
bad copy again.  You'd be deleting your own files and starting another
outbreak!

So, once you've gotten it, *then* delete any more incoming (*bad*)
copies.  Just make @#$% sure your copy isn't going to erase your files
in 1990, or spread.

************ From the desktop computer of Charles Howes, [e-mail]
***** Mind you, I'm not using VMS myself.  These *are* only opinions.
***** Simon Fraser University, Vancouver, BC
***** "Unix is like sex; those who haven't tried it don't know what all the
*****  fuss is about; those who have, can't live without it."

------------------------------

Date:    Mon, 27 Nov 89 20:19:00 -0500
From:    IA96000 <[e-mail]>
Subject: Linkable virus modules

I have heard of, nor have I ever found any modules which were
specifically linked into a program, but I would like some of the
experts to comment on the following possibility:

1) A new or existing virus is developed and produced as a linkable
   object file.

2) Said object file is then either directly linked into an executable
   file at link time, or placed in a run-time library.

Is this even a remote possibility? If so, does anyone have any examples
or know of any examples where this has been done?

I would really like to gather opinions and comments on this possibility.

------------------------------

Date:    Tue, 28 Nov 89 06:25:28 +0000
From:    Tony Locke <munnari!extro.ucc.su.oz.au![e-mail]>
Subject: stoned virus in partition table

We have the stoned virus in the partition table of one of our hard disks
on an IBM-XT clone.

I don't know much about partition tables, but I've tried using
Nortons "WIPEDISK C:" and "SF C:" (low-level format program) both to no
effect. I've even deleted the DOS partition and re-created it.

Can I "wipe" this partition table and start again or do I need a program
to kill it ?

My floppy disk with dos 3.3 is uninfected and write-protected.

Sorry if this is yesterday's news but I'm not a regular reader of this
group.

Thanks in advance (email any help direct to me)

Tony Locke
Sydney University Computing Centre

------------------------------

Date:    Mon, 27 Nov 89 20:46:00 -0500
From:    IA96000 <[e-mail]>
Subject: Traceback (PC)

We recently ran into a problem. A user reported that a hard disk
drive in daily use, had only one file on it. The file was named
tracebck.com or another spelling of the virus name.

The disk label was @traceback and as mentioned all files were
deleted except the one file mentioned. SCAN.EXE identified the
Traceback virus as being present in the file.

Anyone recognize this? Unfortunately the user INSISTED that a
low level format be done on the disk, and could not wait for
someone with some knowledge to get there. The technician did a
screen dump of the SCAN.EXE report and then formatted the disk.

Does this sound familiar to anyone? If so, does the low level format
get rid of the virus? The files were restored from master disks and
as far as we know, the master are not infected.

------------------------------

Date:    27 Nov 89 21:19:53 +0000
From:    [e-mail]
Subject: Re: Where did they come from ? (PC)

In article <[e-mail]> [e-mail] (Fridrik Sk
ulason) writes:
>I am trying to compile a list showing where the various viruses seem
>to have originated. Here is what I have got so far, but I am sure the
>        Stoned                    New-Zealand/Australia

This virus was written two years ago in Wellington, New Zealand.
The author, who has been identified, was a high-school student,
who is now at university.  It seems that another individual
however was responsible for the spreading of the virus.

Geographical Note: New Zealand is *not* part of Australia.

Paul Gillingwater, Computer Sciences of New Zealand Limited
Domain: [e-mail]  Bang: uunet!vuwcomp!dsiramd!csnz!paul
Call Magic Tower BBS V21/23/22/22bis 24 hrs NZ+64 4 767 326
SpringBoard BBS for Greenies! V22/22bis/HST NZ+64 4 896 016

------------------------------

Date:    28 Nov 89 06:40:01 +0000
From:    carroll1![e-mail] (David C. Troup)
Subject: Re: Non-executable viruses


stanton![e-mail] (John Goodman) writes:
    [talk about a non-executable virus]
>Has anyone here seen such a virus?

Ive been working on several virus (or worms) for the Apple since I
read about them back in 86. Since all I had was an Apple IIe, I really
had to come up with some weird ideas for implementation for my
experiments.

What I came up with (in church one night!) was to use a text file that
could be EXEC'd from BASIC (or from the HELLO [startup] program on the
boot disk) that would execute the commands in that text file. This
text file would write a program to memory, that would go and patch
other startup programs with the text file, or a smaller version of it.
No assembly used (I was ignarant back then), and all of it was done in
BASIC with the EXEC'able text files. The programs were REALY difficult
to follow; commands that were writing commands to do DOS functions.
But it worked, and I infected an entire BASIC.101 class in 2 days. By
having the worms cross checking the copy counter (max==21), they
"knew" when they got everyone, and promtly killed themselves without
anyone knowing.

We got computers, we're tapping phone lines, I know that that ain't allowed_
    _______  _______________    |David C. Troup / Surf Rat_2600 hz__________
    _______)(______   |         |[e-mail] : mail______________
 _______________________________|414-524-6809(dorm)/7343(work)______________

------------------------------

Date:    Tue, 28 Nov 89 10:18:56 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Eddie ? (PC)

I was wondering about a text string that appears inside the Dark Avenger
virus:
                Eddie lives...somewhere in time

Wasn't there a character named Eddie in a horror movie ? If so, did this
sentence appear there ?

- -frisk


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  1 Dec 1989    Volume 2 : Issue 250

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Network Virus Scanner (PC)
Re: Eddie ? (PC)
Info on Jerusalem Virus (PC)
Re: Sophisticated Viruses (Mac)
DIR EXEC remedies (VM/CMS)
JUDE Virus (?????) Mac
SCANV50
Relay (Bitnet) interactive virus conference
nVir outbreak (Mac)
Virus Update (PC)
Jerusalem B virus
Jerusalem - D (PC)
Multiple infections (PC)
re: Eagle issues (PC)
DIR EXEC question (VM/CMS)

---------------------------------------------------------------------------

Date:    Tue, 28 Nov 89 08:24:13 -0800
From:    [e-mail]
Subject: Network Virus Scanner (PC)

David Grisham asked about the availability of alternatives to NETSCAN.
Tacoma Software Systems produces a network scanner that's equally as
good if not better than NETSCAN.  In addition, they throw in a
prevention program called VIRSTOP that scans programs before they're
allowed to execute and prevents infected programs from spreading.
It's more expensive than NETSCAN but the combined package is pretty
good.  Their address is:
           Tacoma Software Systems
           7526 John Dower Road, W.
           Tacoma, WA 98467

Tim Grant Curry

------------------------------

Date:    28 Nov 89 19:38:08 +0000
From:    [e-mail] (Rob J. Nauta)
Subject: Re: Eddie ? (PC)

[e-mail] (Fridrik Skulason) writes:
>I was wondering about a text string that appears inside the Dark Avenger
>virus:
>                Eddie lives...somewhere in time
>
>Wasn't there a character named Eddie in a horror movie ? If so, did this
>sentence appear there ?

All Iron Maiden fans will recognise this, although I'm not one of
them, I do know that part of their claim to fame is their sleeve
illustrations, which features a creature known as 'Eddie' The various
sleeves see him evolve, die, resurrect, enter the future, and on the
last one in the ice-age.  The quote has something to do with the album
before, 'Somewhere in Time' which was more successful.

Greetings

Rob

PS. Do the Ohio and/or Den ZUk virus do any damage apart from
formatting track 41 ?? I'd like to know, there isn't much info on
those...

------------------------------

Date:    28 Nov 89 21:29:24 +0000
From:    [e-mail] (Erik Sherk)
Subject: Info on Jerusalem Virus (PC)

Hi Virus Hunters,

    It has been a while since I worked on debrain and I have been
away from this list for some time, so I am a little out of date. Please
forgive me if this has been talked about recently.

    The University of Maryland has been hit by the Jerusalem
Virus. The McAfee programs SCANRES and VIRSCAN have been invaluable
in helping to detect the infection, but they don't help remove it.

    So what I am asking for is:

    1) Is there a Public Domain program that will remove
the virus from a machine?

    2) I would like a detailed description of this virus, i.e.
Is it a boot virus, where in RAM does it live, what INTs does it
steal...

    Please send any info to my mail address, as I don't have
the time to read this list regularly.

Thanx in advance...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Erik Sherk                    [e-mail]
Network Infrastructure                [phone]
Computer Science Center
University of Maryland

------------------------------

Date:    28 Nov 89 21:43:05 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: Sophisticated Viruses (Mac)

[e-mail] writes:
>[e-mail] (Chris Johnson) writes:
>>There would be crashes because it's very common for software that
>>patches traps to have interdependencies between its patches, i.e. one
>>patch depends on data discovered and stored for later use by another
>>patch.  Removing only a portion of such patches will be likely to kill
>>the machine sooner or later.
>> . . .
>>Further, restoring traps to their original values is going to remove
>>all of the patches put in place by the System itself - the patches
>>that keep that machine running inspite of bugs in the ROMs, etc.
>>Also, whole portions of the OS and Toolbox will be removed by
>>restoring traps to their initial values (as taken from the ROM) - this
>>will kill the machine for sure.
>
>So what if I remove system patches? You seem to think that I need to
>call every little routine in ROM to do my dirty stuff. What I need is
>say, ChangedResource, WriteResource and perhaps AddResource. What do
>these traps have to do with OS traps? How many system patches are
>there for these traps?  Do you *really* think that the ROM is truly
>and utterly worthless without the system patches? Do you think they
>wrote routines that didn't work at all and then patched them into
>working? Why would I care if there is some small and obscure bug in
>the ROM that could make my virus crash with prob. .000001%, after all
>that is probably the whole idea with the virus after all!!

The point is that you can't know the interdependencies of traps.
Maybe you can get away with some of what you discuss, but it'll be a
matter of luck more than anything else.  And *no* I don't think that
the ROM is utterly worthless and bug ridden, but most ROMs were
created to operate in the context of much earlier system software and
may not be (without the patches that would normally be in place) ready
to cope with the modern Macintosh.  Beyond that, and perhaps more
significantly, Apple's fixes to the ROMs are often made not to the
routine that has the bug, but to routines invoked *by* that routine
which are likely to be, in and of themselves, unrelated to the actual
bug.  See the ongoing discussion of tail patching in
comp.sys.mac.programmer for a full treatment of this subject.

So I think the probability is actually a bit greater than ".000001%"
that your virus will crash the machine *before* it can replicate
itself.  At which point it's just not a virus anymore.

>I don't claim that the ROM is bug free, but your indirect claim that
>every trap is buggy is pretty heavy. (I got that from the "fact" that
>everything will kill the machine "for sure", in case you wonder).

See above - I certainly didn't mean to claim that everything is buggy.
Also, if I can't be sure something will work, when I program, I look
at it as a guarantee that sooner or later I'm going to crash
somebody's machine.  I still make a good number of mistakes (like most
folks), but I think this kind of paranoia is a good idea and steers me
clear of a lot of other problems.  I like to think that all Mac
programmers will exercise similar care in their approach to
programming issues, but, of course you're right, virus authors may not
bother.

>>Writing well behaved patches is a black art on the best of days -
>>writing the sort of un-patching patches discussed here would make that
>>"black art" look like a carefree romp in the sunlit countryside.  I
>>don't think such patches could be implemented safely, and I don't
>>think anyone clever enough to do so would be wasting his time working
>>on viruses in the first place.
>
>This proves you've missed the point entirely. We're not talking about well
>behaved viruses here. And just because you think no one would write one isn't
>exactly proof that no one will...

I didn't miss any point completely.  The first of my points which you
quote above deals with issue of reliability and practicality - I stand
by that statement.  The second of those points was a psychological
one, it was *not* offered as *proof* of anything, just a statement of
what I believe to be a reasonable opinion.  If you have a different
opinion - that's fine.  I hope you and your opinion are very happy
together.  :-)

>>All in all, I don't think the techniques dealt with in this discussion
>>are significant simply because there are too many reliability and
>>compatibility problems intrinsically linked to them.
>
>I do think they are significant though. The whole point with my post in the
>first place was to make people realize that a virus could bypass the
>protective fences of all anti-viral programs (including Gatekeeper) pretty
>easily (theoretically anyway). What if a virus changed the resource map
>directly without going through the ROM at all? We can't just rely on the
>trivial and obvious protection that Gatekeeper et al. provies.

For the reasons I stated above, I still don't think the techniques
dealt with in this discussion are significant.  This is not to say
that there aren't ways around the various virus protection schemes
currently available - there is not now, nor do I believe that there is
ever likely to be, an infallible anti-virus system for the Macintosh.
Nonetheless, I don't think that these particular techniques will be of
service to anyone in trying to get around anti-virus systems.  Since
the failed attempts to create such a virus could, however, cause a few
victims a lot of damage I thought it was important to comment on the
practicality of these techniques.  Techniques that would safely create
more sophisticated viruses, are techniques that I refuse to comment on
in any public forum.  (In general I also refuse to comment on the
techniques that won't work, but I made a rare exception in this case.)

As an aside, Gatekeeper is more sophisticated than Vaccine, and SAM is
more sophisticated than Gatekeeper (although in ways that aren't yet
important, I'm relieved to say).  Gatekeeper is improving and will
continue to do so - I will not be advertising these improvements
because I do not care to notify would-be virus authors of what
Gatekeeper can and cannot do.  The more they're left guessing, the
better-off the rest of us will be.

Further, Gatekeeper, at least, can only be extended so fast because my
resources (free time, money, etc.) are very limited.  To the extent
that this discussion promotes the creation of newer, more
sophisticated viruses we are all done a dis-service - I can only
extend my tools so fast; if you deprive me of time by accelerating the
development of new viruses, you are *not* promoting the creation of
more sophisticated anti-virus tools, instead you're hindering such
efforts.

If you find the protections offered by Vaccine, Gatekeeper and SAM
trivial, I would encourage you to write a better tool.  I imagine that
a lot of people would be very pleased to see another good tool made
available.

>What we need
>is sophisticated protection schemes, and unless there's no discussion of
>potential viruses we might never come up with these schemes in time.

More to the point, I believe, would be the following statement:
"unless we keep up open discussions of this kind the virus authors may
never come up with the ways to bypass the existing protection
mechanisms."

Sharing of information is great, but offering would-be virus authors
important information isn't.  It'll be a dark victory indeed if we get
the more sophisticated anti-virus tools you desire (quite
appropriately) IN RESPONSE TO the appearance of more sophisticated
viruses made possible by these discussions.

I am sympathetic with the desire for more sophisticated tools
(although I think you underestimate SAM), but I don't believe that
this is the way to make them a reality.  If you'd like to pursue these
issues privately, I'd welcome an email discussion with you.
Seriously.

Best wishes,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Tue, 28 Nov 89 09:54:00 -0300
From:    Marty Zimmerman <[e-mail]>
Subject: DIR EXEC remedies (VM/CMS)

What are other VM/CMS installations doing to slow down the spread of
the DIR EXEC?  I seem to remember that the CHRISTMA EXEC prompted
someone to write a program to scan/clean the SPOOL queue, and I was
wondering if anything similar is available for DIR.

On this subject: how far should system administrators go to protect
users from this type of "letter bomb".  It seems a bit heavy-handed to
purge ANY file from the queue with a filetype of EXEC, XEDIT, or MODULE.
Is it best to let the users fend for themselves, or overprotect them?

Marty Zimmerman
<POSTMAST@IDUI1>

------------------------------

Date:    Tue, 28 Nov 89 10:55:50 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: JUDE Virus (?????) Mac

I saw a posting on VALERT-L stating that a new virus has been found
called the JUDE virus.  Does anyone have any information beyond what
was reported on VALERT-L?  Has this been CONFIRMED to be a virus?
Thanks much.

Greg

Postal address:   Gregory E. Gilbert
                  Computer Services Division
                  University of South Carolina
                  Columbia, South Carolina   USA   29208
                  [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Tue, 28 Nov 89 11:14:12 -0800
From:    [e-mail]
Subject: SCANV50

ViruScan V50 is now out.  It detects the Holland Girl .COM infector
reported by Fidonet SysOp Jan Terpstra in the Netherlands.  The virus
increases the size of infected programs by 1332 bytes and contains a
message about a girl named Sylvia in Holland.  No damage has yet been
reported from the virus.  Will report back when more is known.
Alan

------------------------------

Date:    Tue, 28 Nov 89 21:02:51 -0500
From:    "Doug Sewell" <[e-mail]>
Subject: Relay (Bitnet) interactive virus conference

A few problems with the idea:

1. Access: Quite a number of VIRUS-L/comp.virus readers that might
   wish to participate in an interactive conference are not members
   of the Bitnet/NetNorth/Earn network.  These people could not par-
   ticipate.  I do not know for sure if there are interactive confer-
   encing systems for usenet and internet, but I doubt it... and
   COMPU$ERVE is too expensive.

2. If all the participants were on Bitnet/NetNorth/Earn, the Relay
   network probably wouldn't cooperate - many relay sites have 'quiet
   hours' during the day, and time zone conflicts would have some
   users locked out while other users could participate.  Also, the
   relays I'm familiar with limit a channel to 8-10 participants (but
   I'm not sure if there would even be that many, and I'm not sure
   if the ones with the most to offer are on Bitnet).

It is a nice idea, though.

Doug Sewell ([e-mail]), Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
>> Love it or hate it, your body is yours for life.

------------------------------

Date:    Wed, 29 Nov 89 09:39:44 -0000
From:    <[e-mail]>
Subject: nVir outbreak (Mac)

1. Can I warn people that there has been another outbreak of nVirB
on the Macs at Teesside Polytechnic, Middlesbrough, Cleveland UK.
Please check any disks received from here on or after today.

2. Can I apologise to everyone on VALERT-L who received my complaint
about repeated error messages. It should have gone to VIRUS-L. Sorry
to have put even more unwanted stuff in your mail boxes.

Rgds,

Iain Noble

------------------------------

Date:    Wed, 29 Nov 89 08:39:40 -0600
From:    Bill Hobson <[e-mail]>
Subject: Virus Update (PC)

     I have finally had a reoccurance of the virus that wiped out
several hard disks in our architecture department.  It has positively
identified as Jerusalem B as I had suspected.  I am sure that it won't
be the last outbreak - this has been the fourth outbreak on campus in
less than 6 months (sigh).  I have an unconfirmed report of the Stoned
virus that I am investigating.  More later as the search continues!

------------------------------

Date:    29 Nov 89 20:30:51 +0000
From:    [e-mail] (Jason Griggs)
Subject: Jerusalem B virus

     The Jerusalem B virus started to sweep over the Electrical
Engineering dept. at University of Florida this afternoon.  I'd
appreciate any information as to how the virus works & how to get rid
of it.  Thanks in advance.

||===========================================================================||
||     // //      //---  ||  Gravity: Not just a good idea, it's the LAW!    ||
||    // //_\\   // __   ||  [e-mail]                           ||
|| \\// //   \\ //__//   ||  [e-mail]              ||

------------------------------

Date:    Wed, 29 Nov 89 22:59:20 +0200
From:    "Yuval Tal (972)-8-474592" <[e-mail]>
Subject: Jerusalem - D (PC)

For some reason ViruScan idetifies the sURIV 2 as the Jersualem - D virus.
The sURIV 2 is not a varient of the Jerusalem, it is more likely to be
some kind of 1st of April - EXE virus.

- -Yuval

+--------------------------------------------------------------------------+
| BitNet:   NYYUVL@WEIZMANN        Domain: [e-mail] |
| InterNet: [e-mail]                        |
+-----------------------------------+--------------------------------------+
| Yuval Tal                         | Voice:   [phone]               |
| The Weizmann Institute Of Science | BBS:     [phone] * 20:00-7:00  |
| Rehovot, Israel                   | FidoNet: 2:403/136         (CoSysop) |
+-----------------------------------+--------------------------------------+

------------------------------

Date:    Wed, 29 Nov 89 21:48:16 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Multiple infections (PC)

Some of the early variants of the Jerusalem virus are known to infect the
same file over and over, but it was thought that no other virus did that.

It seems, however, that the Cascade virus does this too, under certain
conditions. One of the software companies here in Iceland called me
today, asking for help in removing a virus which had invaded their
network. It was obvious that something unusual was going on -
COMMAND.COM was over 50K instead of the usual 25K or so. Examination
revealed that programs on their Novell network server had been
infected multiple times (up to 20 times) with the same virus (1704-B),
but programs on diskettes and local hard disks had only been infected
once.

I just used a quick and dirty solution - ran my disinfection program
20 times, but I would like to know if anyone else has noticed this
phenomena.

- -frisk

------------------------------

Date:    Wed, 29 Nov 89 17:56:00 -0500
From:    IA96000 <[e-mail]>
Subject: re: Eagle issues (PC)

Normally I would agree would you. However, many people hunt for VGA
specific applications on BBS's which I guess is why EAGLE.EXE was
said to be a VGA animation of an eagle in flight.

As far as whether it should be considered a trojan, a virus, both
or neither, since two forms of viruses have been detected in it,
and since it is also a trojan, it might be a good idea to consider
as something, don't you think?

EAGLSCAN does not just identify the viruses inside these encrypted
files. Note I said encrypted files. It also hunts for the specific
code used to determine the processor type and the code used to do
the actual disk writes.

In any event, this is the last you will hear on the subject from me.
SWE is swamped with more requests than they can handle and as far as
I am concerned, it is time to turn to another subject.

------------------------------

Date:    Wed, 29 Nov 89 11:59:30 +0000
From:    [e-mail],
Subject: DIR EXEC question (VM/CMS)

My boss has just heard about this and got himself into a flap.  (We run,
among other things, a VM/CMS 'service' (if that word can be applied to
VM/CMS) on a 3090/150S.)

We have not seen a copy of it, and we don't know how BITNET/EARN IBM's
are interconnected.  However it sounds from the description like it
must transfer itself using SENDFILE (or TRANSFER) over something like
RSCS.  Is this indeed the case?  (If so, it is unlikely to travel
freely between UK academic IBM sites as we tend to run UK Bluebook for
file transfers, which requires that you know the password as well as
the username on a remote site in order to send them a file.  If it
travels as mail, then password is not necessary of course, but on the
other hand the mechanics of MAIL are such that a user is more likely
to have looked at it before running it, since it is a bit tricky to
'RECEIVE' mail into a separate executable file.)

Of course if we DID end up with a copy on our machine, it could
redistribute itself freely within the machine.  I'm simply trying to
make a value judgement as to the likelihood of our getting a copy from
outside; and to decide exactly how to phrase our warning to users.  It
also affects our protective reaction.  If it transfers via
SENDFILE/TRANSFER we're not going to get it.  If it transfers via MAIL
or some other protocol, we might get it, but it will not show up in
our SPOOL as DIR EXEC...
 Paul Smee, Univ. of Bristol Comp. Centre, Bristol BS8 1TW (Tel [phone])
 [e-mail]   :-)   (..!uunet!ukc!gdr.bath.ac.uk!exspes if you HAVE to)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  1 Dec 1989    Volume 2 : Issue 251

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

More anti-virals (IBMPC)
Introduction to the anti-viral archives
Amiga anti-viral archive sites
Apple II anti-viral archive sites
Atari ST anti-viral archive sites
Documentation anti-viral archive sites
IBMPC anti-viral archive sites
Macintosh anti-viral archive sites
UNIX anti-viral archive sites
Virus Demos?
Ping-Pong virus version B
Latest VIRUSCAN (SCAN.EXE) version (PC)
Requesting info on Yale Virus (PC)
Information requested
MDISK - Boot virus removing program (PC)
Virus Simulator Found! (PC)
Virus attack [AMIGA]

---------------------------------------------------------------------------

Date:    Tue, 28 Nov 89 23:59:00 -0600
From:    [e-mail] (Jim Wright)
Subject: More anti-virals (IBMPC)

In addition to the files mentioned here, I'm trying to see that
all the IBMPC archive sites are "in sync" with one another.  This
generally means that older files will be sent to sites, but there
are some goodies out there.  After a while, check up on your favorite
archive site.

Short listings...

ckot095.zip     Shell program to use with scanv and archived files
dirtyd9b.zip    Version 9B of the Dirty Dozen list of Trojan programs
fsp_17.arc      FluShot+ v1.7, checksums and resident protection
nobrains.arc    Docs and progs for dealing with Brain virus
scanrs49.zip    Resident program to scan executables for viruses
scanv49.zip     Program to scan files/dirs/disks for viruses
shez491.zip     Shell program to use with scanv and archived files
virstop.zip     Resident program to scan executables for viruses


Long listings...

ckot095.zip
    Update to the shell program for manipulating archives.  (ARC,
    ZOO, PAK, ZIP, LZH, etc.)  Compatible with scanv.  Should fix
    previous problem with deleting files.  DOS4.01 users be cautious.
    This program is meant for command line and batch usage.
dirtyd9b.zip
    Excellent list of Trojan Horse and pirated programs.  As
    for the virus listings, they seem to be in a *very* preliminary
    stage of development.  Two of the "virus" listings include:
    |    COMMAND.COM
    |        This is a traditional Virus.  Originating
    |        in colleges and universities across the
    |        nation, and in particular at Lehigh
    |        College, this virus will embed itself in
    |        COMMAND.COM.
    Remember, command.com is a virus which infects itself, in a
    traditional sort of way. :-)
    |    UNIX
    |        Version 4.3 of UC Berkley's UNIX is
    |        apparently an INTERNET virus which
    |        travels by mail packet.  Beware.
    Got that?  Everybody delete that nasty Unix from your systems. :-)
fsp_17.arc
    Version 1.7 of FluShot+.  Checksums files, and provides runtime
    protection from malicious programs.  One of the many documentation
    files provided is 40 pages long.  There's lots of information
    for beginning to intermediate DOS users.  Apparently this
    announcement slipped through the cracks earlier.
nobrains.arc
    I took a couple existing programs to eradicate the Brain virus,
    found the source code for them and packed it all up together with a
    bunch of informational text.  Starter kit for the brain infected.
scanrs49.zip
    Yet another update.  Includes table of viruses and characteristics,
    plus validation program.
scanv49.zip
    Yet another update.  Includes table of viruses and characteristics,
    plus validation program.
shez491.zip
    Update to the shell program for manipulating archives.  (ARC,
    ZOO, PAK, ZIP, LZH, etc.)  Compatible with scanv.  This program
    is meant for interactive browsing.
virstop.zip
    A program that does essentially what scanres does, but according
    to the author, it's cheaper and it's faster.

Jim


------------------------------

Date:    29 Nov 89 18:20:34 +0000
From:    [e-mail] (Jim Wright)
Subject: Introduction to the anti-viral archives


# Introduction to the Anti-viral archives...
# Listing of 29 November 1989

This posting is the introduction to the "official" anti-viral archives
of virus-l/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

Jim

==== cruft for the lawyers ====

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.  Unfortunately, in this day and age nothing is certain.  It is awful
that these people have to worry about legalities when they are only trying
to provide a free and useful service.

Sigh.


------------------------------

Date:    29 Nov 89 18:24:09 +0000
From:    [e-mail] (Jim Wright)
Subject: Amiga anti-viral archive sites


# Anti-viral archive sites for the Amiga
# Listing last changed 30 September 1989

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    The Amiga index for the virus archives can be retrieved as
        request: amiga
        topic: index
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>

ms.uky.edu
    Sean Casey <[e-mail]>
    Access is through anonymous ftp.
    The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
    The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
    Steve Jenkins <[e-mail]>
    Service for UK only; no access from BITNET/Internet/UUCP
    Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
    FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
    Pull the file "help/basics" for starter info, "micros/index" for index.
    Anti-Viral stuff is held as part of larger micro software collection
    and is not collected into a distinct area.

uxe.cso.uiuc.edu
    Mark Zinzow <[e-mail]>
    Lionel Hummel <[e-mail]>
    The archives are in /amiga/virus.
    There is also a lot of stuff to be found in the Fish collection.
    The IP address is 128.174.5.54.
    Another possible source is uihub.cs.uiuc.edu at 128.174.252.27.
    Check there in /pub/amiga/virus.


------------------------------

Date:    29 Nov 89 18:24:41 +0000
From:    [e-mail] (Jim Wright)
Subject: Apple II anti-viral archive sites


# Anti-viral archive sites for the Apple II
# Listing last changed 30 September 1989

brownvm.bitnet
    Chris Chung <[e-mail]>
    Access is through LISTSERV, using SEND, TELL and MAIL commands.
    Files are stored as
        apple2-l xx-xxxxx
    where the x's are the file number.

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    The Apple II index for the virus archives can be retrieved as
        request: apple
        topic: index
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>

uk.ac.lancs.pdsoft
    Steve Jenkins <[e-mail]>
    Service for UK only; no access from BITNET/Internet/UUCP
    Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
    FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
    Pull the file "help/basics" for starter info, "micros/index" for index.
    Anti-Viral stuff is held as part of larger micro software collection
    and is not collected into a distinct area.


------------------------------

Date:    29 Nov 89 18:25:07 +0000
From:    [e-mail] (Jim Wright)
Subject: Atari ST anti-viral archive sites


# Anti-viral archive sites for the Atari ST
# Listing last changed 30 September 1989

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    The Atari ST index for the virus archives can be retrieved as
        request: atari
        topic: index
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>.

panarthea.ebay
    Steve Grimm <[e-mail]>
    Access to the archives is through mail server.
    For instructions on the archiver server, send
        help
    to <[e-mail]>.

uk.ac.lancs.pdsoft
    Steve Jenkins <[e-mail]>
    Service for UK only; no access from BITNET/Internet/UUCP
    Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
    FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
    Pull the file "help/basics" for starter info, "micros/index" for index.
    Anti-Viral stuff is held as part of larger micro software collection
    and is not collected into a distinct area.


------------------------------

Date:    29 Nov 89 18:25:50 +0000
From:    [e-mail] (Jim Wright)
Subject: Documentation anti-viral archive sites


# Anti-viral archive sites for documentation
# Listing last changed 30 September 1989

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    The index for the **GENERAL** virus archives can be retrieved as
        request: general
        topic: index
    The index for the **MISC.** virus archives can be retrieved as
        request: misc
        topic: index
    **VIRUS-L** entries are stored in monthly and weekly digest form from
    May 1988 to December 1988.  These are accessed as log.8804 where
    the topic substring is comprised of the year, month and a week
    letter.  The topics are:
        8804, 8805, 8806 - monthly digests up to June 1988
        8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests
    The following daily digest format started on Wed 9 Nov 1988.  Digests
    are stored by volume number, e.g.
        request: virus
        topic: v1.2
    would retrieve issue 2 of volume 1, in addition v1.index, v2.index and
    v1.contents, v2.contents will retrieve an index of available digests
    and a extracted list of the the contents of each volume respectively.
    **COMP.RISKS** archives from v7.96 are available on line as:
        request: comp.risks
        topic: v7.96
    where topic is the issue number, as above v7.index, v8.index and
    v7.contents and v8.contents will retrieve indexes and contents lists.
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>

lehiibm1.bitnet
    Ken van Wyk <[e-mail]> new: <[e-mail]>
    This site has archives of VIRUS-L, and many papers of
    general interest.
    Access is through ftp, IP address 128.180.2.1.
    The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
    Steve Jenkins <[e-mail]>
    Service for UK only; no access from BITNET/Internet/UUCP
    Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
    FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
    Pull the file "help/basics" for starter info, "micros/index" for index.
    Anti-Viral stuff is held as part of larger micro software collection
    and is not collected into a distinct area.

unma.unm.edu
    Dave Grisham <[e-mail]>
    This site has a collection of ethics documents.
    Included are legislation from several states and policies
    from many institutions.
    Access is through ftp, IP address 129.24.8.1.
    Look in the directory /ethics.


------------------------------

Date:    29 Nov 89 18:26:24 +0000
From:    [e-mail] (Jim Wright)
Subject: IBMPC anti-viral archive sites


# Anti-viral archive for the IBMPC
# Listing last changed 29 November 1989

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    The IBMPC index for the virus archives can be retrieved as
        request: ibmpc
        topic: index
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>

ms.uky.edu
    Daniel Chaney <[e-mail]>
    This site can be reached through anonymous ftp.
    The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus.
    The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
    Steve Jenkins <[e-mail]>
    Service for UK only; no access from BITNET/Internet/UUCP
    Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
    FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
    Pull the file "help/basics" for starter info, "micros/index" for index.
    Anti-Viral stuff is held as part of larger micro software collection
    and is not collected into a distinct area.

uxe.cso.uiuc.edu
    Mark Zinzow <[e-mail]>
    This site can be reached through anonymous ftp.
    The IBMPC anti-viral archives are in /pc/virus.
    The IP address is 128.174.5.54.

vega.hut.fi
    Timo Kiravuo <[e-mail]>
    This site (in Finland) can be reached through anonymous ftp.
    The IBMPC anti-viral archives are in /pub/pc/virus.
    The IP address is 130.233.200.42.

wsmr-simtel20.army.mil
    Keith Peterson <[e-mail]>
    Direct access is through anonymous ftp, IP 26.2.0.74.
    The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
    Simtel is a TOPS-20 machine, and as such you should use
    "tenex" mode and not "binary" mode to retreive archives.
    Please get the file 00-INDEX.TXT using "ascii" mode and
    review it offline.
    NOTE:
    There are also a number of servers which provide access
    to the archives at simtel.
    WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
    from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
    from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
    (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
    are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
    DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
    EB0UB011 (Spain) and TREARN (Turkey).


------------------------------

Date:    29 Nov 89 18:26:47 +0000
From:    [e-mail] (Jim Wright)
Subject: Macintosh anti-viral archive sites


# Anti-viral archive sites for the Macintosh
# Listing last changed 07 November 1989

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    The Mac index for the virus archives can be retrieved as
        request: mac
        topic: index
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>

ifi.ethz.ch
    Danny Schwendener <[e-mail]>
    Interactive access through DECnet (SPAN/HEPnet):
        $SET HOST 57434  or $SET HOST AEOLUS
        Username: MAC
    Interactive access through X.25 (022847911065) or Modem 2400 bps
    ([phone]):
        # CALL B050 <cr><cr>
        Username: MAC
    Files may also be copied via DECnet (SPAN/HEPnet) from
        57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
    Werner Uhrig <[e-mail]>
    Access is through anonymous ftp, IP number is 128.83.144.1.
    Archives can be found in the directory mac/virus-tools.
    Please retrieve the file 00.INDEX and review it offline.
    Due to the size of the archive, online browsing is discouraged.

scfvm.bitnet
    Joe McMahon <[e-mail]>
    Access is via LISTSERV.
    SCFVM offers an "automatic update" service.  Send the message
        AFD ADD VIRUSREM PACKAGE
    and you will receive updates as the archive is updated.
    You can also subscribe to automatic file update information with
        FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
    Bill Lipa <[e-mail]>
    Access is through anonymous ftp, IP number is 36.44.0.6.
    Archives can be found in /info-mac/virus.
    Administrative queries to <[e-mail]>.
    Submissions to <[e-mail]>.
    There are a number of sites which maintain shadow archives of
    the info-mac archives at sumex:
    * MACSERV@PUCC        services the Bitnet community
    * LISTSERV@RICE        for e-mail users
    * FILESERV@IRLEARN    for folks in Europe

uk.ac.lancs.pdsoft
    Steve Jenkins <[e-mail]>
    Service for UK only; no access from BITNET/Internet/UUCP
    Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
    FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
    Pull the file "help/basics" for starter info, "micros/index" for index.
    Anti-Viral stuff is held as part of larger micro software collection
    and is not collected into a distinct area.

wsmr-simtel20.army.mil
    Robert Thum <[e-mail]>
    Access is through anonymous ftp, IP number 26.2.0.74.
    Archives can be found in PD3:<MACINTOSH.VIRUS>.
    Please get the file 00README.TXT and review it offline.


------------------------------

Date:    29 Nov 89 18:27:17 +0000
From:    [e-mail] (Jim Wright)
Subject: UNIX anti-viral archive sites


# Anti-viral and security archive sites for Unix
# Listing last changed 30 September 1989

attctc
    Charles Boykin <[e-mail]>
    Accessible through UUCP.

cs.hw.ac.uk
    Dave Ferbrache <[e-mail]>
    NIFTP from JANET sites, login as "guest".
    Electronic mail to <[e-mail]>.
    Main access is through mail server.
    The master index for the virus archives can be retrieved as
        request: virus
        topic: index
    For further details send a message with the text
        help
    The administrative address is <[e-mail]>

sauna.hut.fi
    Jyrki Kuoppala <[e-mail]>
    Accessible through anonymous ftp, IP number 128.214.3.119.
    (Note that this IP number is likely to change.)

ucf1vm
    Lois Buwalda <[e-mail]>
    Accessible through...

wuarchive.wustl.edu
    Chris Myers <[e-mail]>
    Accessible through anonymous ftp, IP number 128.252.135.4.
    A number of directories can be found in ~ftp/usenet/comp.virus/*.


------------------------------

Date:    Thu, 01 Dec 89 08:26:11 +0000
From:    munnari!mlacus.oz.au![e-mail]
Subject: Virus Demos? (PC)

 I have seen conflicting descriptions of what the Marijuana virus
displays on the screen.  Not being afflicted myself, touch wood, I
don't know whom to believe.  Three sources I have seen claim that the
"Legalise marijuana" message is seen, and ALan Solomon recently said
at a Melbourne seminar that this message is embedded in the virus
code, and is not seen on the screen.  This anomaly is a minor issue,
but it set me wondering how does the average user (beginner) know when
a virus has struck her/him?  There is no shortage of virusbusters able
and willing to help such people for a fee.

It would be a good idea for someone who has samples of all known
viruses to create a "virus demo" program using something like Dan
Bricklin's Demo for the purpose.  I haven't seen this program (DB's
D), so I don't know if it could mimic all viruses.  It would also not
work with a virus that does its damage in the background and leaves no
screen message.

Our user group would like to create a library of viruses for testing
new antivirus programs, but I appreciate that no self-respecting
custodian of samples would turn over copies to us without some
cast-iron guarantees of keeping the samples under lock and key.  Hence
the suggestion for a harmless virus demo for known culprits that leave
a screen symptom.

Ash Nallawalla, Editor PC Update, Melbourne PCUG.:

=============================================================================
Ash Nallawalla           ?[D?[D?[D      Tel: [phone]  Fax: [phone]
4
ZL4LM/VK3CIT          Postal: P.O. Box 539, Werribee VIC 3030, Australia.

------------------------------

Date:    30 Nov 89 13:58:10 +0000
From:    [e-mail] (Good writers re-write -- not write!)
Subject: Ping-Pong virus version B

At my university, we have a several computers infected with the Ping
Pong virus version B.  What is the easiest way to remove the virus?
Let me rephrase that.  How can I remove the virus without erasing the
data?

 ------------------------------------------------------------------------------
 Santanu Sircar                                BITNET:   [e-mail]
 University of Massachusetts/Amherst           INTERNET: [e-mail]
|-----------------------------------------------------------------------------|
 "A pig ate his fill of acorns under an oak tree and then started to root
   around the tree.  A crow remarked, `You should not do this.  If you lay bare
   the roots, the tree will wither and die.' `Let it die,' said the pig.  `Who
   cares so long as there are acorns?'"
 -----------------------------------------------------------------------------

------------------------------

Date:    Thu, 30 Nov 89 18:27:00 -0500
From:    IA96000 <[e-mail]>
Subject: Latest VIRUSCAN (SCAN.EXE) version (PC)

I just downloaded the latest version of SCAN, and in reading the
documentation file, I noticed that SCAN now uses SELF TEST?

At least that is what it says in the opening paragraph of the
latest documentation file. Did I read it wrong? (It was late at
night!)

------------------------------

Date:    Thu, 30 Nov 89 19:05:34 -0400
From:    Elizabeth Caruso <[e-mail]>
Subject: Requesting info on Yale Virus (PC)

After running VIRSCAN on a Dos 3.1 floppy disk, it reported that the
boot sector was infected with the Yale Virus.  When we booted a pc
with this disk the following message was displayed: "This is a message
from the U.S. Space Fedearation".  Is this message part of the virus
or was it just placed by a user?  WE ARE REQUESTING ANY INFO YOU HAVE
ABOUT THE YALE VIRUS!  Thanks in advance!

------------------------------

Date:    Thu, 30 Nov 89 20:26:12 +0000
From:    "A.G. Miller" <[e-mail]>
Subject: Information requested

AT THIS MOMENT I AM TRYING TO COMPILE A LARGE AMOUNT OF DATA ON
CERTAIN ACTIVITY.  IF ANYONE IN THE GROUP KNOWS OF ANY DETAILS OF
SYSTEMS BEING HACKED INTO OR BETTER STILL SYSTEMS BEING HACKED INTO
AND NASTIES PLACED IN THEM THEN I WOULD LIKE TO KNOW. THIS INFORMATION
IS REQUIRED FOR A STUDY INTO COMPUTER SECURITY AND RELATED TOPICS.

MAIL TO   [e-mail]
ALLAN MILLER
DEPARTMENT OF ELECTRICAL AND ELECTRONIC ENGINEERING.
HERIOT WATT UNIVERSITY
EDINBURGH
SCOTLAND.

THANKYOU........

------------------------------

Date:    Fri, 01 Dec 89 09:05:43 +0000
From:    [e-mail]
Subject: MDISK - Boot virus removing program (PC)

Has anyone used this package? I have tried it to remove Stoned virus
from the partition table of a hard disk and it seems to work ok.
However when I tried to remove the same virus from the boot sector of
a floppy I keep getting an Abort error message - not able to continue
(from the program).  As the documentation on this package is rather
scarce I would appreciate any advice or comment( I have followed the
procedure as given in the documentation several times to make sure I
did it right!).  Our DOS is version 3.3 and I used the MD33 F command
to disenfect floppies.

                Bob.Gowans

PS. I obtained the package from WSMR-SIMTEL20.ARMY.MIL
    PD1:<MSDOS.TROJAN-PRO>MD.ARC.1

JANET:       [e-mail]
Internet:    [e-mail]     Dept Civil Eng,
EARN/BITNET: R.Gowans%MCC.ac.uk@UKACRL              U.M.I.S.T,
UUCP:        ...!ukc!umist!R.Gowans                 Sackville Street,
                                                    Manchester.
FAX:         [044 61  | 061] 200-4016               M60 1QD.

------------------------------

Date:    Fri, 02 Dec 89 00:25:13 +0000
From:    munnari!mlacus.oz.au![e-mail]
Subject: Virus Simulator Found! (PC)

As luck would have it, just hours after I posted my request for a
harmless virus simulation suite, someone gave me a suite of programs
written by Joe Hirst in MS-DOS format archived as VIRSIMUL.ARC.  The
files have a date of 8 Sep 89, so I may not have the latest set.  The
suite contains the more common viruses (simulated) that have visual
effects.

=============================================================================
Ash Nallawalla        Tel: [phone]  Fax: [phone]
ZL4LM/VK3CIT          Postal: P.O. Box 539, Werribee VIC 3030, Australia.

------------------------------

Date:    01 Dec 89 16:16:37 +0000
From:    [e-mail] (George Armhold)
Subject: Virus attack [AMIGA]

The other day someone brought the Byte Bandit virus into our lab.  A
user came in to print from the Amiga using Scribble!.  He booted from
his Workbench and proceeded to have several problems printing to the
Apple Imagewriter II.  After he left I re-booted with my Workbench
which runs VirusX3.20 as part of its startup-sequence.  To my surprise
VirusX reported that the Byte Bandit virus was in memory, and had
infected the disk in df2:!  Removing the virus with VirusX was simple
enough.

My question is, could this virus (Byte Bandit) have been responsible
for the problems we had printing?  We had the right printer driver,
and the preferences settings all seemed OK but it just would not print
properly.  It changed type style randomly, stopped printing half way
through a job, and wouldn't abide to margin settings.  I've never had
this type of problem before with Scribble!, which leads me to believe
that the virus might have had something to do with it. I know that
virii on the Mac tend to affect printing.  Has anyone else experienced
this situation?

- -George

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday,  4 Dec 1989    Volume 2 : Issue 252

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Jerusalem-B in demo progs. (PC)
Jerusalem B virus infection (PC)
A virus story
Trojan Horse Alert - Norton followup (PC)
Is there a SCANV51? (PC)
Re: Info on Jerusalem Virus (PC)
Scanv49/Scanrs49 woes (PC)
Re: JUDE Virus (?????) Mac
Viruses and Anti-Semitism...

---------------------------------------------------------------------------

Date:    Fri, 01 Dec 89 12:11:02 -0500
From:    Laurence Bates <[e-mail]>
Subject: Jerusalem-B in demo progs. (PC)

We have recently located the Jerusalem-B virus on a bunch of VGA demo
programs including Rolex, Raisins, Fuse etc.  I don't suppose these
were the original carriers but it might be worth double checking VGA
demo programs that get passed around.

Fortunately we caught the programs before any harm was done.  They did
infect our SCANV program however.

MANY MANY thanks to the creators of SCANV40.  I'll be in touch with
McAffee Associates but for future reference - which source has the
most recent version of this program?
Acknowledge-To: <LAURENCE@MSU>

------------------------------

Date:    Fri, 01 Dec 89 14:32:42 -0500
From:    [e-mail] (Bill Berbenich)
Subject: Jerusalem B virus infection (PC)

     On Tuesday, Nov. 28, we had an infection of the Jerusalem B virus
here in at least two campus DOS student clusters (56+ machines).  As a
result of regular backups being made of the server in at least one of
the clusters, a verified uninfected restoral was successfully made and
all cluster disks were again checked for infection.  It would appear
that the majority of the damage has been repaired, but it is likely
that there are some infected floppies floating around now. Users are
being advised of this and appropriate software has been installed to
help prevent a reoccurrance of the infection.  More specific
information can be obtained by sending e-mail to me directly.

Bill Berbenich                [e-mail]
Ga. Inst. of Technology        School of Electrical Engineering

------------------------------

Date:    Fri, 01 Dec 89 21:16:03 -0500
From:    [e-mail] (Mr. Brian Seborg)
Subject: A virus story

[Ed. In addition to this story, Mr. Seborg submitted a detailed
description of the Brain virus and his University's encounter with it.
Due to the article's length, I'm sending it out to the
VIRUS-L/comp.virus documentation archive sites rather than including
it here in a digest.  Thanks for the articles Brian.]

                    Inside a Virus Fighter's Head

                            copyright 1989
                           Brian H. Seborg

    Now is the winter of my discontent.  It has been cold all day, and
a looming specter of destruction dampened my spirits.  Would it strike
again?  No one knew whether we were safe in our sheltered system, or
whether we would be wrenched from our tranquility into the
gut-wrenching realization that we had to fight, had to protect
ourselves against the menace that had destroyed so many others who
were caught unprepared.

I looked intently at my screen making sure to note every nuance of my
environment.  The flicker of a drive light sent me into a protective
mode of questioning, "should that have happened?", "was that
legitimate?", "has that happened before?"  The whirring of drives
spinning quietly in place made my body tense, expecting the worst,
hoping that it wouldn't happen, at least not today, not now.  I hadn't
had a chance to back-up many of the bytes which could be forever lost
if today happened to be the day.  God, how I hated those vermin who
had let loose these horrors that destroyed at random the hopes and
thoughts of the innocent.  But they had not gotten to me. No, for I
was not innocent.  Though I had jumped into the breach, I had been
ready.  I am ready.

Though I despise them, I am also indebted to them.  Not for the
destruction they have caused, but for the skill I have been forced to
master in order to fight them. Not because they were skilled, but
because I am more so.  They will not wound me easily, and I will not
be easily dispatched.  I have been victorious in countless battles
which are now but ghosts in my memory.  Only once have I been close to
defeat, but, in the end I prevailed.  My mind saved me when my
defenses had failed.  Not so the Taiwanese.  He had not been so lucky.
He had appeared with his work maimed and crippled.  Most of it beyond
recognition.  But he was brave, and we fought together.  Fought until
we had rooted out and killed the disease which had caused his loss.

Or so we had thought.  One had survived, and lived on in our systems.
Somehow it had gotten through our defenses, though we thought them
impenetrable.  But it was not as smart as I.  Not quite.  I found it.
Found it minutes before it would have destroyed my system leaving my
disk to thrash in agony as my dreams and thoughts evaporated in front
of my eyes.  But it was not to be.  Not on this particular day.  It
reared its ugly head, and I chopped it off at the neck.  I have
preserved its offspring in captivity so that I may learn from them.
But they no longer hold any power over me.

Still, I must watch.  Watch and wait for the next time, for there will
be a next time.  So I stare at my screen spellbound, and listen
intently to the whirring of the drives, their flickering lights
pulsing in the half-light of my office.  I am ready.  To the vermin
and their creations I mentally extend the challenge: Go for it!

------------------------------

Date:    Thu, 30 Nov 89 09:55:44 -0500
From:    "Anthony W. Pieper" <[e-mail]>
Subject: Trojan Horse Alert - Norton followup (PC)

[Ed. From the VALERT-L mailing list.]

                              TROJAN HORSE ALERT
                         ( extracted from Info-IBMPC )

There   is a   file    going  around called    either  NORTSTOP.ZIP or
NORTSHOT.ZIP which, by  it's (sparse) documentation and  the  copyrigh
inside the EXE file, claims  to be from  Norton Computing.  Because of
the  sparse and unprofessionally presented docs,   I looked within the
EXE file and found:

The Norton Public Domain Virus Utility, PD Edition 5.50, (C)1989 Peter
Norton

     Your System has been infected  with a Christmas virus!   Selected
files were just  eliminated!  Without  these files, you might as  well
use your computer as a  damn, boat anchor!  If you  do NOT own a boat,
you may  want  to replace the files   which were just erased.   Try to
determine which files they were.  HARDY HA!  HA!  HA!  HOW DO YOU FEEL
NOW; YOU IDIOT?  MERRY CHRISTMAS AND HAPPY NEW YEAR!

===================
PKUNZIP reports:

 1065  Implode    650  39%  10-04-89  12:26  9778978d --w  READ-ME.NOW
38907  Implode  30156  23%  10-02-89  11:57  c333dec0 --w  NORTSHOT.EXE
- -----          ------  ---                                 -------
39972           30806  23%                                       2

I spoke  with  Craig and Tony from Norton  Computing and it sure ain't
their's.  I DID  run McAfee's SCANV on it,  and it  came up  empty, so
either SCANV simply  can't recognize it, or  it's a prank,  but either
way, it has no business being in circulation.  Be on the look out!

     To: ALL
   From: TONY MCNAMARA
   Subj: Trojan Horse

    We at Peter Norton Computing would like to bring to your attention
an unauthorized trojan horse named NortStop.ZIP or NortShot.ZIP (these
files are the same).  This file was NOT produced with the knowledge or
permission of PNCI.

    This file is not a virus (it does  not infect files).  Instead, it
is  a trojan horse  (it must be run explicitly  to  cause any damage).
When run, it lists the directory and claims the  system is virus-free.
Between December 24th and December 31st, however, it will  erase files
in several directories based on their extensions.

    These   files can be   recognized by their  sizes (NortStop.ZIP is
31744 bytes, NortStop.EXE is 38907 bytes), or  by doing  a text search
for the strings "NORTSHOT.EXE" in the ZIP, "Norton Public" in the EXE.

    If you find or hear of these files,  please contact us immediately
through Tony McNamara, 213/319-2076 (voice), TMCNAMARA 381-9188 (MCI),
or CompuServe (72477,2504).

    Again,   these files are in no   way associated with PNCI.  Please
help us track down and eliminate these files.

    Thank you,
        Peter Norton

************** From the Desk of Mr. James M. Vavrina **************
*            Comm 703-355-0010/0011  AV 345-0010-0011             *
*                  DDN [e-mail]                  *
*******************************************************************

------------------------------

Date:    03 Dec 89 04:44:52 +0000
From:    [e-mail] (Chaim Dworkin)
Subject: Is there a SCANV51? (PC)

Is there a SCANV51 in existance?  The Sunday after Thanksgiving I
called a couple of BBSs in the Boston area and found a file called
SCANV51.ZIP posted on one or two of them.  I looked on Simtel20 and on
vxc.cso.uiuc.edu and could find only SCANV49.

Chaim

------------------------------

Date:    04 Dec 89 07:03:33 +0000
From:    inesc![e-mail] (Julio Raposo)
Subject: Re: Info on Jerusalem Virus (PC)

 I have dealt with a strike of Jerusalem's virus on a friend's PC and
succeded in producing a program to wipe out all viruses from the disk.
Since I claim no copyright over the code I will post it in a few days.

                        Antonio Julio Raposo (ajr@inesc, LISBOA, PORTUGAL)

[Ed. The code, when posted, will be forwarded to the
VIRUS-L/comp.virus PC archive sites.]

------------------------------

Date:    04 Dec 89 13:10:06 +0000
From:    [e-mail] (Julian ANIGBOGU)
Subject: Scanv49/Scanrs49 woes (PC)

I just downloaded and uudecoded Scanv49.arc and Scanrs49.arc from
Simtel. The trouble is that when I try to execute either of them the
pc I'm using hangs! I've used both Dos 3.1 and 3.2 with the same result.
Can some virus guru out there please tell me what I'm doing wrong. I'm
supposed to be looking out for viruses, not to hang the machine! I
know I have a virus stalking around here and somehow attached to all
labelled disks which makes me believe it infected Label.com. Not only
that, I recently bought both Pctools 5.1 and Turbo C 2 & Assembler and
on doing executing simply Dir to check the contents of the diskettes
they all reported one hidden file with size 0 bytes! They couldn't
have left Central Points and Borland already infected! I've just found
out to my discomfort that practically all pc's here are infected.

Please HELP before I send all these stuffs flying through the window!

Thanks in advance.

e-mail: [e-mail]  | Maybe I'm wrong but I have the weird |
                                | feeling I've been out there before.  |
                                ----------------------------------------

------------------------------

Date:    Sat, 02 Dec 89 17:01:09 -0500
From:    [e-mail] (David Gursky)
Subject: Re: JUDE Virus (?????) Mac

There's not much to say about it so far.  It is apparently sufficently
different from other nVIR clones so that older versions of
Disinfectant will not catch it (there is allegedly a Disinfectant 1.3
that will catch it though) but not so different that Virus Detective
will not catch it.

Of course, Virus Detective has the advantage that it will allow the
user to add new search strings for new viruses as they are found.

------------------------------

Date:    Sat, 02 Dec 89 17:06:25 -0500
From:    [e-mail] (David Gursky)
Subject: Viruses and Anti-Semitism...

I could not help but notice that the lastest version of nVIR adds new
resources called "JUDE".  Furthermore, the virus was reported by the
folks over in Switzerland, where German is widely spoken.  Jude is
German for "Jew".  Call me paranoid, but could there be some
connection?

My personal suspicion is that this clone was created by some
anti-semitic group in Germany (which is unfortunately seeing a rise in
anti-semitic acts, as is this country), and that the virus simply made
its way into Switzerland.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday,  5 Dec 1989    Volume 2 : Issue 253

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

New papers on IBMPC viruses
Viruses on Demos and diagnostics
Request for Submissions
Re: Linkable virus modules
The Norton "virus"
Re: Virus attack [AMIGA]
Re: Viruses and Anti-Semitism...
Yale virus (PC)
Jerusalem-B (PC)
Preventing the "Ping Pong" virus (PC)
Re: JUDE Virus (Mac)
Morris Trial Postponed

---------------------------------------------------------------------------

Date:    Mon, 04 Dec 89 14:45:21 -0600
From:    [e-mail] (Jim Wright)
Subject: New papers on IBMPC viruses

Two papers have been added to the anti-viral archives.

solomon.lst     List & description of less common viruses
msdosvir.a89    Virus catalog, with extensive information

solomon.lst
        A description of some of the more recent and obscure viruses
        by Dr. Alan Solomon.  The viruses described include:
                Ogre
                Typo
                Dark Avenger
                Vacsina
                Mix1
                Fumble
                Dbase
        For each virus covered, the following topics are discussed.
                Recognition and detection
                How the virus copies itself
                What the virus does
                How to get rid of it
                Other information
                Technical details
        This information is extracted from the documentation for
        an anti-viral package, and was sent by the author.

msdosvir.a89
        The autumn '89 issue of Dr. Klaus Brunnstein's virus catalog
        for MSDOS computers.  Viruses covered in this are:
                Autumn Leaves = Herbst = "1704" = Cascade A Virus
                "1701" = Cascade B Virus
                Bouncing Ball = Italian = Ping Pong = Turin Virus
                "Friday 13th" = South African Virus
                GhostBalls Virus
                Icelandic#1 = Disk Crunching = One-in-Ten Virus
                Icelandic#2 Virus
                Israeli = Jerusalem A Virus
                MachoSoft Virus
                Merritt = Alameda A = Yale Virus
                Oropax = Music Virus
                Saratoga Virus
                SHOE-B v9.0 Virus
                VACSINA Virus
                Vienna = Austrian = "648" Virus
        A typical entry would have the following sections and
        subsections:
                ==== Computer Virus Catalog 1.2: ====
                Entry, Alias(es), Virus Strain, Virus detected when,
                where, Classification, Length of Virus
                ---- Preconditions ----
                Operating System(s), Version/Release, Computer model(s)
                ---- Attributes ----
                Easy Identification, Type of infection, Infection Trigger,
                Interrupts hooked, Damage, Damage Trigger, Particularities,
                Countermeasures, Countermeasures successful, Standard means
                ---- Acknowledgement ----
                Location, Classification by, Documentation by, Date
                ==== End of Virus ====
        An update scheduled for the beginning of the year should
        almost double the number of viruses cataloged.

Jim


------------------------------

Date:    Fri, 01 Dec 89 14:45:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: Viruses on Demos and diagnostics

Communications Week 11/27/89 p.25 quotes John McAfee to the effect
that most virus infections in the corporate world are caused by
infected demonstration software and diagnostic software sent by
software developers, distributors and other vendors to their
customers.

------------------------------

Date:    Sun, 03 Dec 00 19:89:13 +0000
From:    [e-mail] (Ross M. Greenberg)
Subject: Request for Submissions

(In addition to contacting Ed Wilding, you may also contact me: I'm an
editorial board member.. Ross M. Greenberg, [e-mail])

- -------- Call For Papers and Submissions for Virus Bulletin------

         Anyone wishing to write on any of these topics,  or  wishing
         to  receive the Virus Bulletin notes for contributors should
         contact Edward Wilding, Editor, Virus  Bulletin,  Haddenham,
         Aylesbury  HP17  8JD, UK.  Tel.  [phone]., Tel Int.  +44
         844 290396., Fax [phone],.  Fax Int.  [phone].

         For  circulation  to  Virus Bulletin Editorial Board and all
         interested parties.

               Virus Bulletin copy submission deadlines 89/90.

         Issue 1.6   December 1989   Friday 1st December 1989
         Issue 1.7   January 1990    Friday 22nd December 1989
         Issue 1.8   February 1990   Friday 19th January 1990
         Issue 1.9   March 1990      Friday 23rd February 1990
         Issue 1.9   April 1990      Friday 23rd March 1990
         Issue 1.10  May 1990        Friday 20th April 1990

         (Please note that the copy deadline for Issue  1.7  (January
         1990) is before the Christmas recess).


                             Forthcoming Subjects

         The  following is a list of possible articles in forthcoming
         editions.  These are only suggestions and  I  welcome  other
         ideas or more extended examination than listed.

         1.   Should  we  trust  public  domain  anti-virus software?
         There are many arguments both for and against public  domain
         anti-virus software - this article should attempt to outline
         its  pros  and  cons  and  provide   some   guidelines   for
         prospective users.

         2.   Practical  steps  for  non  experts  in  dealing with a
         network  computer  virus  attack.   What  should   be   done
         immediately by systems administration in the face of such an
         attack?

         3.  Procedural steps to preventing computer virus infection.
         A  checklist  of procedures and rules which if observed will
         minimise the risk of a virus attack.

         4.   Anti-virus   software   evaluation   in   a   corporate
         environment.    By   which   criteria   do  large  corporate
         microcomputer using organisations judge such  software.   Is
         there consensus on this point?

         5.   How  do  you  test  the  value of an anti-virus package
         without having access to computer viruses?

         6.  'Lab'  viruses  versus  'real  world'  viruses.   Is  it
         necessary  for  researchers to create viruses?  What are the
         benefits and does experimentation present any dangers?

         7.  Towards a common terminology  and  nomenclature.   1701,
         Fall, Cascade, Hailstorm, 1704 - how do we overcome the fact
         that there is no agreement  or  consensus  about  naming  or
         classifying  viruses?  Why is this?  Equally, can we develop
         an agreed glossary of terms about the  types  of  virus  and
         their methods of infection?

         8.   Does  commercial  interest  on  the  part of the 'virus
         industry' worldwide inhibit the anti-virus war?

         9.  Case studies.  I should very much like to  recieve  good
         case  studies  which  detail  an  actual  virus  attack, its
         impact, and the methods used to clear  the  infected  system
         and  restore  operations.   Specifics about the organisation
         need not be stated but a clear description of  the  affected
         computer environment is necessary.

         10.   Worm  programs.   Classifying  network vulnerabilities
         and/or analysis of recent worm programs such as Internet  or
         the  two  well  known  NASA  SPAN  attacks.   Are  there any
         universal procedures or  methods  to  prevent  such  attacks
         and/or control them?

         11.   Statistics  about  virus  attacks.   Will  it  ever be
         possible to collate accurate data about the  propagation  of
         computer viruses?  Refusal to report incidents means that at
         best we can only guess about the spread of specific viruses.
         Can we tell how fast a virus will spread by its design?

         12.   Mainframe  viruses/ replicative attack programs.  Fact
         or fantasy?  Specific  incidents  would  be  helpful.   What
         factors  have  served  to suppress mainframe virus writing /
         propagation  /  reports?   Patches  (to   increase   general
         security) for specific machines would be welcome.

         13.   Forensic  evidence.   Most countries have no effective
         legislation to combat computer  misuse.   Even  if  laws  to
         criminalise  virus  creation  are  introduced  (such as that
         recommended by the Law Commission, UK, or implemented by the
         state  of  California, USA) the courts will face a difficult
         task in prosecuting.  Are  methods  available  to  trace  or
         identify  computer  virus  writers?   Would this evidence be
         sufficient to convict in a court of law?


- ---
         Virus dissections  (the  analysis  of  a  specific  computer
         virus)  are  always  welcome.   These should not exceed 2200
         words.   Also  details  for  programmers   providing   virus
         hexadecimal  patterns,  infective  length,  entry  point and
         offset.

------------------------------

Date:    04 Dec 89 04:17:15 +0000
From:    munnari!cavs.syd.dwt.oz.au![e-mail] (John Gardner)
Subject: Re: Linkable virus modules

[e-mail] (IA96000) writes:
>1) A new or existing virus is developed and produced as a linkable
>   object file.
>
>2) Said object file is then either directly linked into an executable
>   file at link time, or placed in a run-time library.

There is a virus on the amiga that looks for an executable that is in the
startup batch file and moves the executable`s code into a data segment and
inserts itself into the code segment.  If it can't find the startup file
it then inserts itself into the dir command.  It is easy to spot as one
of your commands changes size, and you just have to delete that command to
kill it.

- --
PHONE          : [phone]
ACSnet         : [e-mail]

"But that wasn't the question !" - Do Androids Dream Of Electric Sheep

------------------------------

Date:    Sat, 02 Dec 89 23:44:00 -0500
From:    <[e-mail]>
Subject: The Norton "virus"

Has anyone that has seen this NORTSHOT.ZIP know if the
McCafee SCANRES or EXERUN will detect it if you run the
obnoxious file.  I have heard that the file doesn't bother
anything unless you explicitly execute it and that SCANV
doesn't detect it.  Maybe these will find it if it is
executed? [Kids, don't try this at home!!]

Chris
ACSCS@SEMASSU
Business Info. Systems Major
Southeastern Massachusetts University
N.Dartmouth, MA 02747

------------------------------

Date:    Tue, 05 Dec 89 13:59:28 +0000
From:    [e-mail]
Subject: Re: Virus attack [AMIGA]

[e-mail] (George Armhold) writes:
> My question is, could this virus (Byte Bandit) have been responsible
> for the problems we had printing?  We had the right printer driver,
> and the preferences settings all seemed OK but it just would not print
> properly.  It changed type style randomly, stopped printing half way
> through a job, and wouldn't abide to margin settings.  I've never had
> this type of problem before with Scribble!, which leads me to believe
> that the virus might have had something to do with it. I know that
> virii on the Mac tend to affect printing.  Has anyone else experienced
> this situation?

I've never heard of Byte Bandit affecting printing, but you generally
can't predict what a virus will do on someone else's system. There are
too many variables and virus code is generally too badly written. The
only answer is, if the problems show up with the virus in memory and
not without it then the virus caused them.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
VMS:  [e-mail]
UNIX: [e-mail]

------------------------------

Date:    05 Dec 89 07:51:49 +0000
From:    boulder!boulder![e-mail] (JOHNSON RICHARD J)
Subject: Re: Viruses and Anti-Semitism...

[e-mail] (David Gursky) writes:
>I could not help but notice that the lastest version of nVIR adds new
>resources called "JUDE".  ...  Jude is
>German for "Jew".  Call me paranoid, but could there be some
>connection?
>My personal suspicion is that this clone was created by some
>anti-semitic group in Germany...

Well, my personal opinion is that someone used a random name generator
to pick a four character resource type.  Then again, it could be a
virus from the depths of the USSR's intelligence community, released
to sow dissension among groups in W. Europe and distract them from the
momentous events in E. Europe.  What use is speculation, though?

When someone catches the "author" of this latest nVIR clone, I think
the first question he or she will be asked by the tabloid reporters
is, "Was the virus a feeble attempt at an anti-semitic statement?"
Until then, I'll stick to the random name "theory."

| Richard Johnson                           [e-mail] |
|    CSC doesn't necessarily share my opinions, but is welcome to.     |
|  Power Tower...Dual Keel...Phase One...Allison/bertha/Colleen...?... |
|   Space Station Freedom is Dead.  Long Live Space Station Freedom!   |

------------------------------

Date:    Fri, 01 Dec 89 16:17:37 -0500
From:    Naama Zahavi-Ely <[e-mail]>
Subject: Yale virus (PC)

Hello!

The Yale/Alameda virus is essentially harmless.  The message you
report was not present in the version of the virus that I am familiar
with; are you sure it comes from the virus and not from some line in
the autoexec.bat file?  If it does come from the virus, then you are
dealing with a different version than the one I know and you should
take my information with a grain of salt.

The Yale virus that I know is a boot sector virus.  It is easy to get
rid of -- boot the computer from a clean, write-protected floppy and
give the command SYS x:, with x: being the drive holding the infected
disk.  The Yale virus that I know does not infect hard disks.

I hope this helps!  Best wishes,
- -Naama

------------------------------

Date:    Mon, 04 Dec 89 10:37:00 -0500
From:    [e-mail]
Subject: Jerusalem-B (PC)

  At S.U.N.Y, Stony Brook, two of our computer labs (about 30 PS/2 50
and PC/XT machines) have been hit by the Jerusalem-B virus.  We have
used B.R.M's UNVIRUS, and IMMUNE programs to successfully combat it so
far.

  Could someone please send me a detailed description of what exactly
this critter does.  Thanks in advance.

=================================================================
THOMAS B. THOMAS
Micro Systems/Analyst
Instructional Computing            BITNET: TTHOMAS@SBCCMAIL
Computing Center            INTERNET: [e-mail]
State Univ. of New York            VOICE: [phone]
Stony Brook, NY 11794-2400

------------------------------

Date:    Mon, 04 Dec 89 10:42:00 -0600
From:    "Roger Safian, VAX Systems Group" <[e-mail]>
Subject: Preventing the "Ping Pong" virus (PC)

Greetings,

    We seem to have an outbreak of the "Ping Pong" virus here at
Northwestern University.  I am wondering if there is some sort of
anti-ping-pong utility out there.  Is there such a thing that would
allow writes to a disk, but only if it is not to the boot blocks?
What is the best way to combat this beast.  I think we have version B
here, as it infects floppies as well as hard disks.

    On a related subject, what is the latest version of viruscan?

                                        Thanks in advance
                                           Roger Safian

------------------------------

Date:    04 Dec 89 21:09:00 +0100
From:    [e-mail]
Subject: Re: JUDE Virus (Mac)

Yes the "Jude" virus is for real. However, so far it only has shown up
at the University of Zurich and Swiss Federal Institute of Technology
(ETH) Zurich, Switzerland. It is an exact clone of nVIR type B; the
only difference being the name of the viral resource which has changed
form "nVIR" to "Jude".

VirusDetective 3.1 positively identifies the new virus as nVIR strain.
Both Vaccine and GateKeeper successfully prevent an infection.
GateKeeper will, however, let through some of the "Jude" resources,
but no contagious infection results.

New versions of Disinfectant (version 1.3) and other anti-viral tools
should be out real soon.

   Markus Mueller
   Institut fuer technische Informatik und Kommunikationsnetze
   Eidgenoessische Technische Hochschule
   CH-8092 Zurich
   Switzerland

   Switch : [e-mail]
   ARPA   : [e-mail]
   UUCP   : [e-mail]
   X.400  : G=markus;S=mueller;OU=inf;O=ethz;P=ethz;A=arcom;C=ch

------------------------------

Date:    Tue, 05 Dec 89 11:23:25 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Morris Trial Postponed

[Ed. Thanks for typing this article in, Tom!]

Quoted from COMPUTERWORLD - December 4, 1989 - page 17

     `Morris seeks classified data' by Michael Alexander, CW Staff

SYRACUSE, N.Y. -- The trial of Robert T. Morris Jr., the young hacker
alleged to have launched a worm into the Internet last year, was
postponed last week after his lawyer notified the court that he needs
access to classified information he claimed is critical to the case.

    Additionally, Morris' lawyer, Thomas Guidoboni, charged that the
government had not responded quickly enough to requests for a list of
computer sites allegedly struck by the worm.

    "The trial was postponed at my request over government opposition
because we needed more time to prepare," Guidoboni said.

    In a motion filed Nov. 21 for a continuance, Guidoboni said that
the defense had filed for a motion under the Classified Information
Procedures Act (CIPA) requesting classified information important to
the case.  In the same motion, Guidoboni said the government had
failed to provide him with a complete list of the institutions that
the government intended to prove had been affected by the worm and a
list of witnesses it intended to call.

    "I have been told that some of the information that is useful to
my case is classified," Guidoboni said.  "It may or may not be.  I
don't want to overplay it or belittle it, but we needed some time to
get that worked out.

    "Less than two weeks before the trial [on Nov. 20], the government
added new names to the list that were not mentioned in the indictment
as well as filed a motion to withdraw one of the original names
mentioned," Guidoboni said.  "I wanted time to look into that."

    In opposition to the motion for a continuance, government lawyers
said that the national security issues raised in the CIPA motion were
being resolved and would have no effect on the defense's ability to
proceed or on the timing of the trial.

    Responding to the issue of not having responded in a timely manner
to the defense's requests for a list of victims or witnesses it
intended to call, "the government has complied with all court orders
to provide discovery," said Mark Rasch, trial attorney for the Justice
Department.  In addition, the defense has had ample opportunity to
request and receive additional information related to the case, he
said.

    The government is seeking in a motion to remove the U.S. Air Force
Logistics Command at Wright Patterson Air Force Base in Dayton Ohio,
from a list of four sites mentioned in the jury indictment as having
been allegedly hit by the worm.

    Rasch declined to comment on why the government wishes to remove
this particular site from its list of victims, while adding that it
intended to offer evidence on 16 sites in all.

    Guidoboni filed an objection to that motion last week, and a
decision is pending.

    Last week, U.S. District Judge Howard Munson agreed to continue
the case to the week of Jan. 8.  A new trial date has not been set.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  6 Dec 1989    Volume 2 : Issue 254

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: nVir outbreak (Mac)
VIRUSCAN Versions (PC)
Jerusalem-B antidote? (PC)
Request for virus info (PC)
Information on Mac Viruses
New VirusX v4.0 is out and the BGS-9 virus (AMIGA)
Re: Jude virus - Disinfectant (Mac)
JUDE Virus: confirmed (Mac)
Strange Video Problems? virus? (PC)
Strange video - addition (PC)
Viruses which infect LAN

---------------------------------------------------------------------------

Date:    05 Dec 89 18:43:53 +0000
From:    [e-mail] (Fred Segovich)
Subject: Re: nVir outbreak (Mac)

Can anyone tell me what the symptoms/effects of nVir A and B are?  I
have an infection here, but no apparent damage.

tnx,
Fred

------------------------------

Date:    Tue, 05 Dec 89 07:49:52 -0700
From:    Chris McDonald <[e-mail]>
Subject: VIRUSCAN Versions (PC)

A reader asked the current version of Viruscan.  There was at least
version 50 as of Friday, 1 Dec.  Version 49 available on Simtel20 does
search for 51 known MS-DOS viruses, including variants.  Perhaps BBS
administrators chose to label Version 49 as "51" for this reason.

Also, I have used Data Physician, a commercial set of programs for
MS-DOS virus protection for several years.  I noticed that a recent
upgrade contained a "Beta Test" version of a program called "VirScan".
As the name implies, the program provides a similar function as
Viruscan.  I ran Viruscan, Version 49, against the program and
Viruscan alarmed on the presence of the Jerusalem virus, Version B and
the Cascade virus (1701).  Since I subsequently saw no infection
action, it is my belief that this was a "false" positive.  I have
notified the vendor, Digital Dispatch, Inc., of the occurrence.  Has
anyone else encountered a similar experience?

Chris Mc Donald
White Sands Missile Range
 --------

------------------------------

Date:    Tue, 05 Dec 89 08:57:32 -0500
From:    Laurence Bates <[e-mail]>
Subject: Jerusalem-B antidote? (PC)

Is it possible to undo the effects of the Jerusalem-B so that stricken
EXE and COM files can be safely used?  Thanks...
Acknowledge-To: <LAURENCE@MSU>

------------------------------

Date:    05 Dec 89 09:26:57 -0500
From:    [e-mail]
Subject: Request for virus info (PC)

  WE HAVE THE 'BRAIN' AND THE 'PING-PONG' STRAINS IN OUR PC LABS.
PLEASE FORWARD ANY INFORMATION ON THESE TWO STRAINS OF VIRUS.
DO YOU KNOW ANYONE WHO MIGHT HAVE A GOOD SOFTWARE TO DISINFECT OUR
PC LABS?  I HAVE SOME INFORMATION ON SOFTWARE THAT MIGHT
DISINFECT PC/XT, BUT WOULD LIKE TO FIND OUT MORE ABOUT THIS
PROBLEM FROM ANYONE WHO MIGHT HAVE SOME EXPERIENCE WITH IT.
I HEARD THE 'SCANV47' SOFTWARE IS NOT QUITE EFFECTIVE AGAINST
THE '(C) BRAIN' VIRUS, BUT IT KILLS THE 'PING-PONG' VIRUS.
IF YOU HAVE ANY EXPERIENCE IN DEALING WITH PC VIRUS PROBLEMS, MY
QUESTION TO YOU IS, WHAT CAN A SOFTWARE DO TO PREVENT VIRUS PROBLEMS
IN AN OPEN PC LAB WHERE THERE IS NO PHYSICALLY CONTROLLED ACCESS
TO THE PC/XT MACHINES?...PERHAPS, NOT MUCH!

  ANY SUGGESTIONS FROM YOU ON HOW TO MANAGE VIRUS PROBLEMS IN
A PC LAB WITH NO PHYSICALLY CONTROLLED ACCESS WILL BE APPRECIATED.

  THANK YOU.
_______________________________________________________________
E-MAIL ADDRESS:              *  BELLARMIN SELVARAJ
                             *  WORCESTER STATE COLLEGE
MAILER: BELL SELVARAJTAYLOR *  486 CHANDLER STREET
BITNET: BELLRCN.BITNET      *  WORCESTER,MA 01602, U.S.A
                             *  TEL: [phone], EXT. 8664
_______________________________________________________________

------------------------------

Date:    Tue, 05 Dec 89 10:43:32 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Information on Mac Viruses

I am trying to compile a file with information pertaining to
mischievious programs running on a Mac.  I have Disinfectant
documentation and that is very helpful and useful.  (Thank you very
much John Norstad et al.)  However I would like as much information as
possible for my files.  Any info or comments are appreciated and you
can find me at the address (either e-mail or US MAIL below).  Thank
you very much.

Greg

Postal address:   Gregory E. Gilbert
                  Computer Services Division
                  University of South Carolina
                  Columbia, South Carolina   USA   29208
                  [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    05 Dec 89 13:16:30 -0500
From:    [e-mail] (Earle Ake)
Subject: New VirusX v4.0 is out and the BGS-9 virus (AMIGA)

        The BGS-9 virus is real and out there.  I just got the newest
VirusX program from Steve Tibbett and ran it on my system.  It found
the BGS-9 virus on my workbench disk, my backup copy of my workbench
disk and two other disks.  I had a few friends also find it on their
disks.  The virus seems to inflict damage on the first executable file
in your startup sequence.  It infests itself in it and moves part of
the original code to df0:devs/.  The file shows up there without a
filename (or it is masked somehow).  VirusX v4.0 is out and will
find/kill that virus.  It can be had on compuserve and is showing up
on many of the Amiga BBS's throughout the country.  Better check your
system, it may be infected.
_____________________________________________________________________________
             ____ ____    ___
Earle Ake   /___ /___/ / /     Science Applications International Corporation
           ____//   / / /__                 Dayton, Ohio
- -----------------------------------------------------------------------------
Internet: [e-mail]    uucp: uunet!dayvb!fac2

------------------------------

Date:    Tue, 05 Dec 89 16:32:36 -0500
From:    Frank Steele <[e-mail]>
Subject: Re: Jude virus - Disinfectant (Mac)

 I've sent along a copy of Disinfectant 1.3. The new version recognizes the
"Jude" virus and fixes a few other bugs.....
 -------------------------------------------------------Frank-------------

------------------------------

Date:    Tue, 05 Dec 89 22:54:08 +0000
From:    ethz![e-mail] (Danny Schwendener)
Subject: JUDE Virus: confirmed (Mac)

[e-mail] (Gregory E. Gilbert) writes:
>I saw a posting on VALERT-L stating that a new virus has been found
>called the 'Jude' virus.  Does anyone have any information beyond what
>was reported on VALERT-L?  Has this been CONFIRMED to be a virus?

Yes. I have received and analyzed an application infected with this
virus. It is another nVIR B clone. MacMASH has been very active these
days to update the existing anti-virus tools. The results so far: -
Disinfectant 1.3, who now correctly detects and removes this strain -
SAM 1.2 (idem)

Trap watchers like Vaccine and GateKeeper don't neet to be updated for
this new strain. Some disk browsers like Antipan 1.3 already detect
all nVIR B clones, and therefore don't need to be updated either.

- -- Danny

+-----------------------------------------------------------------------+
| Danny Schwendener, Apple Developer Services Switzerland               |
| AppleLink: danny.s              UUCP   :   {cernvax,mcvax}ethz!macman |
| Internet:  [e-mail]   Voice  :   yodel three times          |
+-----------------------------------------------------------------------+
DISCLAIMER: These are my very own opinions. Leave my employer alone.

------------------------------

Date:    06 Dec 89 02:35:47 +0000
From:    boulder!tramp![e-mail] (BAILEY CHRISTOPHER R)
Subject: Strange Video Problems? virus? (PC)

I'm having some very strange problems with my video output on both my
home computer system and my universities PS/2's.  My home system is an
XT clone (V20-10, Phoenix bios), and the PS/2's I've noticed it on are
55SX's that are networked with Novell.  Both systems have monochrome
video, mine with a hercules clone and Samsung flat screen and the
PS/2's with some card and I think 8513 mono monitor.

My problem is that starting about column 12 or so, to column 30 or so,
the characters and such in that reagion (any row), jump up about 5 or
10 lines and stay there.  This reeks havoc as far as command lines and
such.

I first noticed this in Telix, my terminal program.  It has done it
without fail everytime in Telix since, sometimes when not even
connected.  The s screen just looks garbled.  It usually takes about
10 minutes for it to happen.  This was on my home machine.  I have
also noticed it using my editor, Multi-Edit v4.00.  I could just PgUp
then PgDn in ME and it would be fixed, same with Q Edit, but I can't
do anything about it in Telix, not even clearing the screen fixes it.
I then started using ZComm instead of Telix, but it did wierd things
there too, mostly just a specific graphic block character was
interspersed between things and the screen was a little out of order.
Later I began getting Internal stack errors and messages such as this,
but I think that was due to my disk cache (which I remedied by adding
stack space - I think).  Anyway, I started to use the Engineering
Centers' computers instead of mine.  Just today my editor did the same
trick, that specific section/column of the screen jumped.  Until
today, I thought I had a memory chip gone bad or something, but why
would it do it on the PS/2's also?  My only clue now is that it's some
type of virus or something.  But I doubt that.  My command com is
fine, and the floppy I'm using at the EC doens't have Command.COM on
it, and I've copied my backup of Telix over mine and it still has the
same problem.  As for my system and the floppy, the only thing they
have in common as far as files go (it's a 1.44MB 3.5") is about 10
Turbo Pascal source code files, and their respective compiled version
and my editor - Multi Edit.  I had been using Multi-Edit for about 3
months before this happened, so I doubt it's the problem.  I have also
had problems with Turbo Pascal environment on my system, but I don't
use it, I just use the command line compiler, and the same goes with
the engineering center.  I haven't even compiled code on my system for
about 2-3 weeks and I still have my problem.

Any ideas????  Any programs I can use to test my system?  The only
think that comes to mind is a worm or logic bomb type of thing.  I saw
them do a "viruscan" at the engineering center about 3 or so weeks
ago.  Help anyone...

Chris Bailey :: [e-mail]
One Agro Mountain Biker - Dialed in for ultra gonzo badness!
"No his mind is not for rent, to any god or government" - RUSH
Member of Team Buck Naked of Buckingham Palace

------------------------------

Date:    06 Dec 89 02:42:00 +0000
From:    boulder!tramp![e-mail] (BAILEY CHRISTOPHER R)
Subject: Strange video - addition (PC)

I forgot to say, when I exit telix, then re run it, the screen is
still messed up.  However, if I reboot my system the screen is ok the
next time I run Telix.  As for the editors, to get rid of it, all I
have to do is the PgUp, PgDn sequence, no reboot is necessary.  Thanx.

Chris Bailey :: [e-mail]
One Agro Mountain Biker - Dialed in for ultra gonzo badness!
"No his mind is not for rent, to any god or government" - RUSH
Member of Team Buck Naked of Buckingham Palace

------------------------------

Date:    Wed, 06 Dec 89 17:51:03 +0700
From:    "S. Yeo" <[e-mail]>
Subject: Viruses which infect LAN

I am doing some research on viruses which are capable of infecting LAN
and I am looking into area such as :

- - how normally viruses get into a LAN
- - how these viruses spread
- - can viruses such as Jerusalem, Ping-pong, Stoned which infect stand-
  alone PC infect LAN server as well
- - will the server be infected if a network user who after established a
  link with the server, run an infected program from his harddisk

I'll be very much appreciate if someone out there who have the info or
experience dealing with virus in a LAN environment share some(if not
all) of the info/experience with me. You can send the info to this
list (if you think it will be of interest to the list readers) or you
can send direct to me at [e-mail]

Thanks in advance for all your help.

S. Yeo

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday,  7 Dec 1989    Volume 2 : Issue 255

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Differences... (PC)
Re: scan problems (PC)
I need a copy of m-jruslm.arc (PC)
SCAN Versions (PC)
Strange video - VIRUS SOLVED (PC)

---------------------------------------------------------------------------

Date:    Wed, 06 Dec 89 14:26:50 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Differences... (PC)

The question "How many different PC viruses are known ?" is a hard one.
The two main reasons why it is so:

1) Some viruses have been reported, but not made available for research,
   so nobody has been able to compare them to existing viruses. In some
   cases there are even doubts that the viruses in question exist at all.
   The viruses in this group are "4096", "Nichols", "Missouri", "Agiplan",
   "Retro" and "Screen".

2) Even when the viruses are available for study, it is often hard to
   determine if two viruses are different or not.

   Consider the following possibilities:

      I Binary identical. No problem here - the viruses are identical.

     II Code is identical on the binary level - text strings changed.
        Some of the variants of "Brain" are a good example.

    III Identical on assembly language level. One example includes viruses
        created by typing in a disassembly and then assembling it, using an
        assembler different from the one originally used. Different
        assemblers will in many cases create different opcodes for the same
        instruction. (the POP/PUSH instructions for example). An example
        is the two variants of the "South African" virus that I have. One
        is an original, the other is created using the disassembly by Jim
        Goodwin.

     IV Minor changes to code, extra NOP instructions added or other changes
        made that have no effects on the function of the virus, but may
        invalidate search strings. The "Lisbon" virus is a good example
        of this.

      V Minor changes to code, different lengths, bug corrections, different
        activation dates and similar changes. Most of the 1701/1704 variants
        fall in this category, but also "Saratoga", "2930","Mix1-B" etc.

     VI Identical replication code, different functions. The "Sunday" virus
        is a good example of this. Also "Ghost", "1704-Format", "Typo" and
        "Advent".

    VII Partially identical code - very different functions. "Fu Manchu"
        is the best example.

   VIII Different code - identical functions. Example: The "ping-pong"
        effect in the MIX-1 virus.

     IX Different code, Functionally identical replication and/or infection
        mechanism. Different functions. No problem - different viruses.

So, what do we do ?  We need to define when we consider two viruses to be...

        ...different viruses
        ...different strains of the same virus
        ...not to be considered different

Of course we can proceed from a different angle - select a few identification
strings for each virus and then classify new viruses as follows:

      ... contains all the identfication strings of the old one -> same

      ... contains some of the identification strings -> new variant

      ... contains none of the identification strings -> new virus


Or maybe use this method:

      ... the new virus can be removed by using the same program that was
          used to remove the old one -> identical

      ... only a single constant or two need to be changed to make it
          possible to use the same program to disinfect -> new variant

      ... new disinfection program/routine must be written -> new virus.

My opinion is that those two suggestions are practically useless, since two
different people working on the same virus may not reach the same conclusion.

comments/suggestions ?

- -frisk

------------------------------

Date:    Wed, 06 Dec 89 10:44:52 -0400
From:    Ken Bell <[e-mail]>
Subject: Re: scan problems (PC)

> I just downloaded and uudecoded Scanv49.arc and Scanrs49.arc from
> Simtel. The trouble is that when I try to execute either of them the
> pc I'm using hangs!

From the combination of this and the next quote, I'd guess that he's
trying to execute the .ARC files directly instead of unarcing them
first.

> know I have a virus stalking around here and somehow attached to all
> labelled disks which makes me believe it infected Label.com. Not only
> that, I recently bought both Pctools 5.1 and Turbo C 2 & Assembler and
> on doing executing simply Dir to check the contents of the diskettes
> they all reported one hidden file with size 0 bytes! They couldn't
> have left Central Points and Borland already infected! I've just found
> out to my discomfort that practically all pc's here are infected.

Yeah.  It's the disk label (hidden file, 0 bytes).
Acknowledge-To: <SYKLB@NASAGISS>

------------------------------

Date:    06 Dec 89 23:01:47 +0000
From:    boulder!tramp![e-mail] (BAILEY CHRISTOPHER R)
Subject: I need a copy of m-jruslm.arc (PC)

I need someone to MAIL me a copy of m-jruslm.arc (avail most ftp
places) because for some reason whenever I download from an ftp site,
and then download it to my machine, these archives don't work.  I'm
not sure whats wrong at this moment.  So if someone could mail me the
Jeruselum/ 1813 virus disinfector I'd really appreciate it!  I need it
soon, have a computer program due tomorrow.

Chris Bailey :: [e-mail]
One Agro Mountain Biker - Dialed in for ultra gonzo badness!
"No his mind is not for rent, to any god or government" - RUSH
Member of Team Buck Naked of Buckingham Palace

------------------------------

Date:    Wed, 06 Dec 89 13:28:31 -0800
From:    [e-mail]
Subject: SCAN Versions (PC)

This is a forward from John McAfee:

        The latest version of SCAN is SCANV50.  While version 51 will be
released on December 10, the currently reported V51, unless a re-numbered
version of an earlier release, is not legitimate.  If anyone has a copy
of this file, please upload it to HomeBase at 408 988 4004.
        On another issue:  Bob Gowan, Erik Sherk and others have inquired
about disinfectors (programs that can remove viruses and repair infected
files) for the various viruses.  The individual disinfectors on HomeBase
(M-JRUSLM for the Jerusalem, M-DAV for Dark Avenger, etc.) have been and
still are available for public download.  These individual disinfectors
exist for the more common viruses, and SCAN version 50 and above contains
a list of each virus and the required shareware disinfector.
       In addition, a program called VIRUS CLEAN is available for emergency
access on HomeBase.  This program disinfects all of the known PC viruses.
It is not a shareware product, but free access is provided for emergency
situations.  For emergency access, call voice at 408 988 3832 for
instructions.

John McAfee

------------------------------

Date:    07 Dec 89 07:15:58 +0000
From:    boulder!tramp![e-mail] (BAILEY CHRISTOPHER R)
Subject: Strange video - VIRUS SOLVED (PC)

Well, the strange video problems I was having were on account of the
1813 or Jeruselem (A I think) virus.  I was able to remedy it by
deleteing all the infected files and replacing them with safe backups.
I used IBM's VIRSCAN program to detect it.  I had been infected in 717
places (about 60 files worth), and some floppies.  I then tried
VIRSCAN on my roommates disks, and found he had the Bouncing Ball
virus!  Sheesh!  OUr network is submerged!  Thanks, I no longer need a
remedy/disinfectant!

Chris Bailey :: [e-mail]
One Agro Mountain Biker - Dialed in for ultra gonzo badness!
"No his mind is not for rent, to any god or government" - RUSH
Member of Team Buck Naked of Buckingham Palace

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  8 Dec 1989    Volume 2 : Issue 256

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Virus Buster v2.00 (beta) (PC)
Re: Signature programs
WDEF Virus Alert (MAC)
Video problem (PC)
Network Virus Protection (Mac)
WDEF Virus (Mac)

---------------------------------------------------------------------------

Date:    Thu, 07 Dec 89 16:07:16 +0200
From:    "Yuval Tal (972)-8-474592" <[e-mail]>
Subject: Virus Buster v2.00 (beta) (PC)

Hello!

I am looking for a few beta-testers for the new version of Virus
Buster.  The current version of VB is 1.10 and a new 2.00 will be
released soon. I need people who have special hardware (large HD,
special graphics adapter etc).  People who like to volunteer for this
task should send e-mail to Yuval Tal ([e-mail]) or to
one of the addresses written at the end of this letter.

Ok, here is some info about Virus Buster 1.10:

Virus Buster is an anti-viral software that was written in Israel by
Uzi Apple ([e-mail]) and by me. It can identify and
remove about 15 viruses (version 2.00 will remove about 23) including:
Data-crime, Jerusalem, 1st of april, Saratoga, FuManchu, Icelandic and
more! Most important thing: It is PUBLIC DOMAIN! No fee charged! It
has windows, statistics and much more. It will be soon available on
the SIMTEL20 directories.

- -Yuval

+--------------------------------------------------------------------------+
| BitNet:   NYYUVL@WEIZMANN        Domain: [e-mail] |
| InterNet: [e-mail]                        |
+-----------------------------------+--------------------------------------+
| Yuval Tal                         | Voice:   [phone]               |
| The Weizmann Institute Of Science | BBS:     [phone] * 20:00-7:00  |
| Rehovot, Israel                   | FidoNet: 2:403/136         (CoSysop) |
+-----------------------------------+--------------------------------------+
|   "Always look on the bright side of life" *whistle*  -  Monty Phyton    |
+--------------------------------------------------------------------------+

------------------------------

Date:    Thu, 07 Dec 89 14:33:11 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Signature programs

  Bob Bosen has posted a couple of articles on "signature" programs
(I prefer to call them "checksum" programs).  I agree with some of
what he has written, but disagree with other portions.  In V2 #249 he
asks Steve Woronick:
>                                              Are you saying you could
>write or describe a virus that could infect a program but avoid
>detection by an off-line ANSI X9.9-based message authentication code?

  I don't know what Steve's answer is, but mine is definitely YES, and
I say that even though I know very little about the ANSI X9.9 algo-
rithm.  Bob and many others, particularly those with backgrounds in
cryptology, tend to emphasize the *algorithm*: X9.9 or DES or RSA
is considered by the experts to be more secure than CRC, and that's
all there is to it.  What they miss is the fact that what has to
ensure security on a computer is not simply an algorithm, but rather a
*program* which implements it in a given *operating system*.  And even
a program based on the most sophisticated checksum algorithm in the
world is circumventable if it is not written *very carefully*.
  Take, for example, the PC checksum programs in the directory <MSDOS
TROJAN-PRO> or <MSDOS.FILUTL> of the Simtel20 archives.  They all use
a CRC (or in a few cases a more primitive) algorithm.  Suppose we
choose one of them and replace the CRC algorithm by the ANSI X9.9
algorithm.  Will that ensure security?  Far from it!  For one thing,
most of these programs have no provision for checksumming the boot
sector.  That means that despite the use of a sophisticated algorithm,
these programs would be totally ineffective against boot-sector virus-
es, and that includes a sizable percentage of existing viruses.
  Boot-sector checksumming is available in a few of these programs,
e.g. it was finally added to the FluShot+ program a few months ago.
But to the best of my knowledge this program still does not have
partition-record checksumming.  And that goes for almost all the other
programs in those directories also (Sentry is a welcome exception).
  But is checksumming the BS and PR all we need to worry about?  Defi-
nitely not.  If we perform the checksumming when memory is infected by
a Brain-type virus, even X9.9 won't detect any modification.
  So now all we have to do is ensure that memory is uninfected when we
perform the checksumming (by booting from a clean diskette, etc.).
Right?  Wrong!  There are at least five other loopholes in PC-DOS/
MS-DOS which a virus writer could exploit if the program is not care-
fully written, all of which are independent of the checksum algorithm
and do not depend on memory being infected.  (These have apparently
never been used in any actual virus so far.)  Exploitation of such
loopholes is much more practical (from the point of view of the virus
writer) than the checksum-forging methods alluded to by several people
in this forum, since they are independent of the checksum program and
do not require any calculations (of checksums, polynomials, keys,
etc.).  True, all of these loopholes can be blocked if the author of
the checksum program thinks of them.  The trouble is not only that
most authors do not, but also that there may be other loopholes which
none of us has thought of yet.
  The conclusion is that even a program based on the most sophistica-
ted checksum algorithm in the world cannot be depended on to detect
all infections.  Whether a given algorithm is secure depends heavily
on how it's implemented as a *program* in a particular *system*.
  If it's relevant, Bob, I would suggest that you raise this issue
with the rest of the ANSI working group.  There's a small problem,
however:  I have not publicly specified what these additional, more
subtle loopholes are, since I feel it would be quite irresponsible of
me to do so.  But somewhere around No. 89 on my list of 927 things to
do is writing virus simulators to implement all, or at least most, of
these loopholes.  If Bob or anyone else is willing to send me a PC
program which implements X9.9 or any other signature algorithm which
he thinks is secure, that would raise the priority of my writing at
least one of these simulators, which I could then throw at the program
in order to test whether it really is secure.

  Bob also asks:
>                                                   Who can say whether
>the more sophisticated viruses of the future will attempt to analyze
>CRC signatures or target specific products that rely on CRC methods?

  Since he specifically mentions CRC methods, he is obviously not re-
ferring to the types of loopholes to which I alluded above.  In V2
#238 I gave arguments against the claim that CRC programs are circum-
ventable in practice by checksum-forging methods, provided certain ob-
vious precautions are taken.  Bob has given no reply to these argu-
ments and I don't see how emphasis on *future* viruses affects them
(except possibly as concerns the time required for the virus to do its
work).  While I obviously can't prove it, my personal feeling is that
*in practice* a CRC algorithm based on a randomly or personally chosen
generator is, and will remain, just as secure as any more sophistica-
ted algorithm (if the CRC base and program are kept offline) and pro-
bably a lot faster.  In any case, the most important thing is the pro-
gram, not the algorithm.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

Date:    Thu, 07 Dec 89 10:55:38 -0700
From:    Pete Troxell <[e-mail]>
Subject: WDEF Virus Alert (MAC)

This is being cross-posted from comp.sys.mac. The original article is
by John Norstad of Northwestern University:

A new Macintosh virus named "WDEF" has been discovered in Belgium,
at Northwestern University, and at the University of Texas.

The WDEF virus infects the invisible "Desktop" files used by the
Finder.  Every Macintosh disk has one of these files (hard drives
and floppies).  The virus spreads from Desktop file to Desktop
file, but it does not infect applications, data files, or system
files.

The virus does not intentionally try to do any damage.  In fact,
it doesn't do anything except spread from disk to disk.

Due to a bug, the virus causes Mac IIcis to crash.  We have also
noticed unusually frequent crashes on infected Mac IIcxs, and
severe performance problems with infected AppleShare servers.
There are also other bugs in the virus which could cause problems.

You do not have to run a program for the virus to spread.

Unlike most of the other Mac viruses, the WDEF virus is not spread
via the sharing and distribution of programs, but rather via the
sharing and distribution of disks, usually floppy disks.

You can eliminate the virus from a disk by rebuilding the desktop
file (hold down the Command and Option keys while booting or while
inserting a floppy).

Jeff Shulman, the author of Virus Detective 3.1, recommends adding
the following search string to detect the virus:

    Creator=ERIK & Resource WDEF & Any

Virus Detective can also be used to remove the virus - click on
the "Remove" button whenever the search string is matched.  This
only works if you are not using MultiFinder, and if you are
running some program other than the Finder.  Don't try this with
the other viruses - Virus Detective can only repair WDEF
infections, not infections by the other known Macintosh viruses.

As far as we know, Virus Detective is the only virus-fighting tool
which can detect the new WDEF virus.

Unfortunately, the virus manages to avoid detection by all of the
popular protection INITs, including Vaccine 1.0.1, GateKeeper
1.1.1, SAM Intercept 1.10, and Virex INIT 1.12.

Disinfectant 1.3, Virus Rx 1.5, SAM Virus Clinic 1.10, and Virex
2.12 also all fail to detect the virus.

We expect that many of the virus-fighting programs mentioned above
will be updated soon to deal properly with the new WDEF virus.

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208

[e-mail]

- --
Peter Troxell
NET:     ncar!dinl!troxell
ARPA:    [e-mail]
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
         Denver, CO 80201-1260
Phone:   [phone]

------------------------------

Date:    07 Dec 89 20:55:51 +0000
From:    [e-mail] (Thuan-Tit Ewe)
Subject: Video problem (PC)

Regarding your posting, I know of a virus which will do just such a thing.
After disassemblying Jerusalem B virus, I saw code in there triggered by
the clock interrupt that will scroll a region of the screen some two lines
up.

Your best bet is to use any anti-viral program to check your system and
make sure it's not affected. Also, to see if it a virus attact:

1. Get a good copy of any small program from a floppy. (Maybe debug.com from
   your DOS distribution)
2. Note its size
3. Run the program that will cause the screen scroll. (Or any wierd problem)
4. Exit program on step 3, and execute the small program.
5. Exit the small program and check to see if the size increased.

If it does, chances are very, very, very good that you have a virus problem!

Of course, if the small program has already been infected, you won't see
any size increase.

Thuan-Tit Ewe                   MetaWare Inc
[e-mail]                [phone]
{uunet|ucscc|acad}!metaware!tte

------------------------------

Date:    Thu, 07 Dec 89 15:47:27 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Network Virus Protection (Mac)

Is there any freeware that will provide virus protection when using a
network such as AppleShare or TOPS?  I know SAM will work fine.  Will
Gatekeeper or Vaccine provide adequate protection?  Will Disinfectant
provide adequate diagnosing capabilities?

Greg

Postal address:   Gregory E. Gilbert
                  Computer Services Division
                  University of South Carolina
                  Columbia, South Carolina   USA   29208
                  [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Fri, 08 Dec 89 11:42:58 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: WDEF Virus (Mac)

Recently there was a posting on VALERT-L about a new virues, WDEF.  In the
alert it is mentioned that:

(stuff deleted)

"Jeff Shulman, the author of Virus Detective 3.1, recommends adding the
following search string to detect the virus:

CREATOR=ERIK & Resource WDEF & Any

Virus Detective can also be used to remove the virus ......"

Where or to what do we add the "following search string".  Please
pardon my ignorance.

Greg

Postal address:   Gregory E. Gilbert
                  Computer Services Division
                  University of South Carolina
                  Columbia, South Carolina   USA   29208
                  [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 11 Dec 1989    Volume 2 : Issue 257

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Ping Pong B (PC)
Re: Network Virus Protection (Mac)
Seagate drives (PC)
Wiping out Jerusalem's virus (PC)
WDEF (Mac)
Jerusalem B virus found (long story)
Re: WDEF Virus (Mac)
re: DIR EXEC remedies (VM/CMS)
Disinfectant 1.4 (Mac)
Protecting Users form Letter Bombs
Use of Digital Signatures
JUST WHAT IS *LSD? (Mac)
SCANV51 (PC)

---------------------------------------------------------------------------

Date:    Fri, 08 Dec 89 15:23:22 -0500
From:    Peter Jones <[e-mail]>
Subject: Ping Pong B (PC)

We have a PC virus in our labs, which is detected as Ping Pong B by
SCANV49, and as the Ping Pong Virus by IBM's virus scanner. Unlike the
Ping Pong described in file MSDOSVIR.A89, it does not have the bytes
1357 at offset 1FCO.

The virus appears to be a boot-sector virus; it has not been detected
by SCAN in the .COMs or .EXEs. As with Ping Pong, a strange character
(not a lower-case 'o') bounces around the screen. Sometimes the "ball"
bounces off a non-blank character. Sometimes characters fall down.

The virus appears to be triggered, like Ping Pong, when a disk access
occurs near a quarter-hour. CHKDSK issued about 5 seconds before such
a time usually does it.

Occaisonally, we have observed two independent "balls" on the screen.
We have been unable to cause this behaviour deliberately on our test
PC.

The virus can be spread by an infected boot sector on non-system data
diskettes, if the user accidentally leaves such a diskette in drive A
and tries to boot from it, then presses any key to continue booting
after the "non-system disk" message from DOS.

Questions for you readers:

1) Is there a complete description of the virus available?

2) What damage does it do?

3) What prevention and disinfection procedures can be used
   a) in computer labs with many users per machine
   b) in professor's office (few people using a machine)

(I've read about the idea of scanning the diskettes used by students
in labs before giving the diskette to another student.)

4) Is there a version of SCANVRS that will detect boot-sector viruses on data
   disks? Aside from disk utilities such as Norton's absolute sector editor,
   is there a simple way to disinfect a data disk? SYS A: after a clean boot
   doesn't work because there isn't space for a system on A:.

Peter Jones     MAINT@UQAM     (514)-987-3542
"Life's too short to try and fill up every minute of it" :-)

------------------------------

Date:    08 Dec 89 22:53:47 +0000
From:    emx.utexas.edu!ut-emx![e-mail] (Chris Johnson)
Subject: Re: Network Virus Protection (Mac)

[e-mail] (Gregory E. Gilbert) writes:
>Is there any freeware that will provide virus protection when using a
>network such as AppleShare or TOPS?  I know SAM will work fine.  Will
>Gatekeeper or Vaccine provide adequate protection?  Will Disinfectant
>provide adequate diagnosing capabilities?

Gatekeeper will work fine - just install it on all your machines.
'Makes no difference what sort of file server (if any) that you use.
If Gatekeeper sees an attack taking place, it stops it - no matter
what sort of volume the attacker is stored on.  This is equally true
of SAM and Vaccine, but I wouldn't recommend Vaccine.

Vaccine requires (1) that your machine is only used by highly skilled
users/ programmers, i.e. people who always know how to respond to the
Granted/Denied queries and (2) that the viruses be very simple -
Vaccine's protections are minimal compared to Gatekeeper (and I'm
currently working on further extending Gatekeeper's protections.)

I hope this helps,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Fri, 08 Dec 89 14:29:34 -0600
From:    James Ford <[e-mail]>
Subject: Seagate drives (PC)

Question 1: (PC)
Some (all?) Seagate drives come with a program called DM.  This
program lets you set the partitions to whatever size, etc.  It also
includes an option to allow you to set a partition to "read-only".
Would this be effective against any/some/all boot infectors, IBMBIOS,
IBMDOS and COMMAND.COM infectors?  How hard would it be to get around
this program (DM)?

Question 2: (all)
Could the PC, MAC, or TI99/4A wizards post some of their methods of
protecting their files/machines from infection(s)?  Right now, I just
use SCANRES, but have been thinking about spending the time to install
some other (PC) programs (FluShot, Sentry, etc) on my machine.  What
would be the best combination?

For those of you who are keeping records of various infections, the
Jerusalem Virus version "B" was detected yesterday by SCAN V50.  The
machine infected was a PS/2 Model 50, located in the graduate students
office.  It was noticed when a grad student kept getting strange
results when running Turbo Pascal (machine slowdown).  The disks that
have been in contact have been re-formatted (micros, that is) and the
search is on for the disk that origionally brought it to the machine.

James Ford - [e-mail]  "Gee, a one-line tag..............."

------------------------------

Date:    09 Dec 89 13:50:43 +0000
From:    inesc![e-mail] (Julio Raposo)
Subject: Wiping out Jerusalem's virus (PC)

1:
This is the C source of a program I made to clean the JERUSALEM's virus
from the EXE and COM files, restoring those files to their original state.
Just cut between the start -- end lines and compile.

2:
I have no access to FTP sites, so can anyone (preferably from EUROPE, it is
cheaper) mail me virus scan programs for the IBM PC - DOS ?

==============================<start of C source>===========================
[Ed. Due to its length, I'm forwarding the C program to the archive sites.]
==============================<end of C source>=============================

                       Antonio Julio Raposo  (ajr@inesc, LISBOA, PORTUGAL)

------------------------------

Date:    Sat, 09 Dec 89 10:15:08 -0500
From:    "Frank Steele" <[e-mail]>
Subject: WDEF (Mac)

 The new WDEF virus for the Mac has infected some of the Mac labs at
the University of Georgia. I've had a chance to see its effects, here
are a few: If your machine is infected, WDEF slows down window
updates. You may hang in the middle of trying to open or close a
window. Generally, the arrows in your monitor's upper left-hand corner
(denoting network connection) will show during the entire process
(they usually blink) and, if you're closing a window, you may see the
radial lines within the close box even long after (15-30 sec) you've
clicked in it. From my understanding of the proper role of the
W(indow) Def(inition) resource, this makes sense. The spooler window
on an AppleShare window can take a similarly long time to update. I
can't tell yet whether the virus can spread to/from AppleShare servers
over the network (or only by disk contact) or whether the special
desktop files, Desktop DB and DF, associated with AppleShare servers
can be infected (None I've seen so far have been).  Further input from
others on these possibilities would be appreciated. Also, I don't
think infection is automatic. I checked a floppy disk belonging to a
user who had been using an infected hard drive for an hour, and the
floppy was clean.
 Virus Detective, version 3.1, will search for the resource and will
remove it.  In fact WDEF is the only virus I'm aware of that Virus
Detective can safely remove. Others?) Don't be intimidated by the
rather lengthy dialog box telling you that removing a single resource
won't necessarily remove a virus. In this case, it will. One problem
I've seen is that, if you're running Symantec Anti- virals for the
Mac, telling Virus Detective to remove the resource brings up an alert
box disallowing you (in about five different ways) from changing any
resources, then bombs the machine. Therefore, if you're using SAM,
disable it until you've removed WDEF, then re-enable it.
 This is one of the more innocuous viruses to hit the Mac, but the
unusual propagation method is going to make it extremely difficult to
completely clean up, especially in an unattended environment, as many
campus Mac labs are.
 I'll be happy to help anyone with questions as much as I can through
BITNET...  I'd appreciate hearing from others with additional
information (Has anyone this apart and discovered whether it has a
purpose beyond propagation?)... My address is [e-mail].

Frank Steele

------------------------------

Date:    Sat, 09 Dec 89 13:27:57 -0500
From:    [e-mail]
Subject: Jerusalem B virus found (long story)

FOR THOSE WHO RESPONDED TO MY PREVIOUS VIRUS POSTING, I HAVE THIS STORY
FOR YOU:
                   How I got Jerusalem virus in my computer

                         A user's nightmare came true

            (88 lines long, anything longer than that would be VIRUS...)

To make a short story long, let me go back to some day in late
September....

     I was playing with my computer, as usual, and my wife was doing
her works in the kitchen, as usual.  I was using PC Tools to copy some
of my files from hard disk to floppy and when I went back to root
directory in C:, I saw an empty file that was new and weird to me.  It
looked like this in PC Tools:

     Filename      File length   Attribute    Date

     gEgEgEgE.gEg       0          .SR.     11/07/14

Since I have deleted countless files using PC Tools, I tried the same
way to select that file and delete it.  To my surprise, PC Tools
responded "File not Found".  So I said to my self:"It must be the
problem of zero length." and tried to write something on it so I can
delete it, and you know, it didn't work that way.  And the strange
thing was that whenever I changed its attribute by using Edit/View
function, it didn't work as it supposed to be.

     So I kept that file and forgot it until someone on campus(or Wall
Street Journal) brought up the issue of October 13th and computer
virus attack.  I went to 12 Willard to get a scanv4 disk and used it
to scan my hard disk for at least 13 times and did not spot a virus.
I was still nervous about the virus attack, so I got another virus
protection program (Flushot, in case it matters) and checked the hard
disk again and again and again until my wife reminded me to do
homework.  I survived the virus hit in October.

     Before the first snow in November about three weeks ago, I booted
up the machine as usual and press the turbo switch when I noticed the
slow speed of computer checking my Intel Aboveboard memory.  The
computer suddenly went nuts for the first time since I bought it a
year ago.  There was nothing on the screen, the keyboard didn't
respond, and the speaker beeped.  I powered off and on again and the
computer prompted me "8237 Error" and refused to work.  I was nervous
but not afraid.  Since I have played around with computers for a
while, I tore down my machine to check what might be the source of
error.  I didn't find anything suspicious but BIOS and DMA.  I went to
a local computer store and had my BIOS replaced and the computer
worked again.  So I gave them $35 for the Phoenix BIOS that worked
wonder on my computer.

     But honeymoon soon was over.  One day when I was using my
primitive word processor PFS:Professional Write, the computer hung me
without any warning.  I lost all my editing file and had to reboot it
again using reset button not ctrl+alt+del.  And after that, it hung
from time to time whenever I changed from editing document to print or
to spell check.  After few days, I found out I cannot use turbo mode
anymore, I had to stay with normal mode.  When I press the turbo
button to boost speed, I got hung.

     Since I just replaced BIOS, I suspected the problem is in DMA.
So I brought my computer back to that local store after Thanksgiving
and they said that I need a new motherboard because they cannot fix
the motherboard problem.  Because they were asking ONLY $200 for a new
12MHz 286 motherboard, I decided to get it replaced.  Everything
worked fine with the new board until I tried to run Harvard Graphics,
it hung again.  Same thing happened to Minitab and the new
PFS:Professional Write v2.0.  I questioned the store about the
compatibility of that kind of motherboard and got pissed off.  They
claimed that their motherboard has been running thousands of software
and has never encountered non compatible problem.  So I tested
everything I could, changing faster memories, changing different BIOS,
changing video board, and even swapping hard disks.  I could not find
out the problem until someday I used MAPMEM to see memory usage and
saw an unknown program occupying about 1732k memory above
configuration and dos command and I realized that something weird was
going on.

     I immediately (well, next day) got the virus detection disk from
office and started checking my hard disk.  Boy, was I astonished!  I
saw a warning line as soon as I issued SCAN command: SCAN file has
been damaged....  In the next few minutes, I saw 50 of my command
files were infected by Jerusalem B virus.  I used pctools to erase all
infected files and got a map of my hard disk to see if everything is
ok.  But I saw some secctors marked "unremovable" where they should be
"usable" space.  And I realized that the only way to get rid of the
virus would be reformatting my entire hard disk.  So I did.  I am glad
I have a back up for every program I have in the hard disk.

     Now all the viruses are gone except one that I keep in a floppy
as a memory or for future research use, I start thinking where I got
this little virus.  There are only two places: PCLIB at Penn State or
that computer store.  I cannot think of any other sources except these
two.  The weired file with 0 byte and unremovable is from some file in
PCLIB, but I have checked every file before October 13 and found no
virus.  After that date, I have not downloaded anything.  On the other
hand, every weired thing started after I replaced BIOS and used
testing software from the computer store.  It's also possible that the
virus is attached to some file that store has.  I will keep tracking
down the suspicious source of this virus and if anything comes out
interesting, I will summarize and post it.

                                                    GOOD   BYE !
                                                   _____    ___
H. WU       [e-mail]                       _|_    |___|
            DEPARTMENT OF BUSINESS LOGISTICS       |_|_|   |___|
            THE PENNSYLVANIA STATE UNIVERSITY     _|_|_|_  |___|
                                                   |   |   _/ |__|

------------------------------

Date:    Sat, 09 Dec 89 18:07:23 +0000
From:    yale!slb-sdr!sdr.slb![e-mail] (Jeff Shulman)
Subject: Re: WDEF Virus (Mac)

[e-mail] (Gregory E. Gilbert) writes:

>Recently there was a posting on VALERT-L about a new virues, WDEF.  In the
>alert it is mentioned that:

>(stuff deleted)

>"Jeff Shulman, the author of Virus Detective 3.1, recommends adding the
>following search string to detect the virus:

>CREATOR=ERIK & Resource WDEF & Any

>Virus Detective can also be used to remove the virus ......"

>Where or to what do we add the "following search string".  Please
>pardon my ignorance.

>Greg

These instructions only apply to VirusDetective 3.x

1. Select VirusDetective from the DA menu.
2. Click the Modify Search Strings button.
3. Type
        Creator=ERIK & Resource WDEF & Any ; For finding WDEF, etc.
4. Click the Add button.
5. Click the Save button.
6. That's it!

Specific instructions can be found both in the VD doc file, online
docs and is going to be mailed out to registered users early this
week.  I will also be posting a file full of the latest search strings
that you can read in by clicking Read from File instead of steps 3 &
4, and I will be posting VD 3.1a that has this string already built in
(NO code modifications were made).

If you are a registered user and you still need more assistance don't
hesitate to contact me either electronically or by phone.

Jeff Shulman
VirusDetective Author

As usual, this is *me* speaking and no other organization.

uucp:      ...rutgers!yale!slb-sdr!shulman
CSNet:     [e-mail]
Delphi:    JEFFS
GEnie:     KILROY
CIS:       76136,667
AppleLink: KILROY

------------------------------

Date:    Sat, 09 Dec 89 19:10:00 -0500
From:    "Gerry Santoro - CAC/PSU 814-863-4356" <[e-mail]>
Subject: re: DIR EXEC remedies (VM/CMS)

Marty Zimmerman <[e-mail]>  writes:

>What are other VM/CMS installations doing to slow down the spread of
>the DIR EXEC?  I seem to remember that the CHRISTMA EXEC prompted
>someone to write a program to scan/clean the SPOOL queue, and I was
>wondering if anything similar is available for DIR.

At Penn State we are taking a broader approach.  The systems folks
here may be scanning spool files for a file named DIR EXEC (don't
really know if they are), but we've also placed a logon warning
message talling users not to receive and execute *ANY* EXEC unless
they know exactly what it does.

Although DIR EXEC and CHRISTMA EXEC (also distributed as XMAS EXEC)
cause well-known havok, it is rather easy for a mischevious student to
send a custom EXEC to an unwary faculty/staff/student who then tries
it out to see what it does.

I did a poll of some of my students (i teach computing for humanities
here) and was horrified at how many of them were given 'neat' EXECS by
perfect strangers, which they then proceeded to use and distribute to
others.  Not a single one of them reads REXX and they had no suspicion
that any of these EXECS could be doing something behind their backs.

Another common problem here is that eager students will 'customize'
the environment of faculty who are novices to VM/CMS by linking them
to their (the students) disks, which have lots of custom EXECs on
them.  At the very least, when the student graduates and their account
disappears we get questions about the faculty regarding why "the
computer dosen't work anymore".

gerry santoro, ph.d.                         *** STANDARD DISCLAIMER ***
center for academic computing              This  posting   is  intended  to
penn state university              |       represent  my personal opinions.
gms @ psuvm.psu.edu              -(*)-     It is not representative  of the
gms @ psuvm.bitnet                 |       thoughts or policies  of  anyone
...!psuvax1!psuvm.bitnet!gms               else here or of the organization.
[phone]                               ---- "I yam what I yam!" ----

------------------------------

Date:    Sun, 10 Dec 89 00:10:16 -0500
From:    [e-mail]
Subject: Disinfectant 1.4 (Mac)

Disinfectant 1.4 is a new release of our free Macintosh virus
detection and repair utility.

Version 1.4 detects and repairs infections by the new WDEF virus (see
below).

In version 1.4 we no longer refer to the various clones of the nVIR B
virus by name.  We refer to them simply as generic "clones of nVIR B."
All references to the individual clone names have been removed from
both the document and the reports generated by the program.

We feel that the creators of these clones do not deserve the publicity
they receive when they see the names they have chosen in print,
especially since some of the names are offensive.

Disinfectant 1.4 is available now via anonymous FTP from site
acns.nwu.edu [129.105.49.1].  It has also been posted to
comp.binaries.mac, info-mac, and CompuServe, and should be available
from those sources soon.

The following text is extracted from the new section on WDEF in
Disinfectant's online document.  It describes what we know to date
about this new virus.

The WDEF virus was first discovered in December, 1989 in Belgium and
in one of our labs at Northwestern University.  It has also been
reported at several other major US universities, so we fear that it
may be widespread.  We also have reason to believe that the virus has
been in existence since at least mid-October of 1989.

WDEF only infects the invisible Desktop files used by the Finder. With
a few exceptions, every Macintosh disk (hard drives and floppies)
contains one of these files.  WDEF does not infect applications,
document files, or other system files. Unlike the other viruses, it is
not spread through the sharing of applications, but rather through the
sharing and distribution of disks, usually floppy disks.

WDEF spreads from disk to disk very rapidly. It is not necessary to
run a program for the virus to spread.

Although the virus does not intentionally try to do any damage, WDEF
contains bugs which can cause very serious problems. In particular,
one bug in the virus causes the Mac IIci to crash. We have also
noticed unusually frequent crashes on infected Mac IIcxs, and severe
performance problems with infected AppleShare servers. Several people
have also reported frequent crashes when trying to save files, and we
have two reports that the virus can damage disks.

When using Disinfectant to repair WDEF infections, you must use Finder
instead of MultiFinder. Under MultiFinder the Desktop files are always
busy, and Disinfectant is not able to repair them. If you try to
repair using MultiFinder, you will get an error message.

Unfortunately, none of the current versions of the most popular virus
prevention tools are effective against the WDEF virus. This includes
Vaccine 1.0.1, GateKeeper 1.1.1, Symantecs SAM Intercept 1.10, and
HJCs Virex INIT 1.12.  However, by the time you read this, it is very
likely that new versions of these tools will have been released.
Symantec and HJC are preparing new releases of their products, and we
expect that a free prevention tool or tools will also be available
soon.

This version of Disinfectant is being released only a few days after
the discovery of the WDEF virus. We do not yet understand it as
thoroughly as we do the other older viruses.  We have disassembled it
completely, and we understand the basic replication mechanism. We know
that it can cause serious problems, and we know why it causes some of
the problems.  Research into the behavior and adverse effects of this
virus will continue for some time.

You should keep in touch with your local Mac user group or bulletin
board for more information about this new virus as it becomes
available. Commercial online services like CompuServe and Genie and
the Macintosh trade press publications like MacWeek are also good
sources of information.

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208

Bitnet: jln@nuacc
Internet: [e-mail]
CompuServe: 76666,573
AppleLink: A0173

------------------------------

Date:    Sun, 10 Dec 89 10:17:00 -0500
From:    [e-mail]
Subject: Protecting Users form Letter Bombs

>On this subject: how far should system administrators go to protect
>users from this type of "letter bomb".  It seems a bit heavy-handed to
>purge ANY file from the queue with a filetype of EXEC, XEDIT, or MODULE.
>Is it best to let the users fend for themselves, or overprotect them?

A reasonable compromise is to protect them from surprise by arbitrarily
renaming and re-typing the object so that they will not execute it by
accident.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Sun, 10 Dec 89 10:51:00 -0500
From:    [e-mail]
Subject: Use of Digital Signatures

I suspect that Y. Radai misses the point of Bob Bosen's posting.

The point is, why re-invent the wheel thinking up new authentication
schemes when standard ones of known strength already exist.  He was not
making knew claims about how effectively such schemes can be implemented.

However, there is a more subtle point.  In the most general, non-trivial
(read PC), case, a virus designer cann always get his program executed
by duping users.  The law of large numbers suggests that, as Abraham
Lincoln said, you can always fool some of the people some of the time.
If the population is sufficiently large, that will be enough to insure
the life of the virus.

Again, in the most general non-PC case, an effective way to get a
program executed is to make it appear to come from a known and trusted
source.  The Christmas cards are a good example.  When the copies are
distributed they are distributed under the source ID of the last victim.
Since the names of the targets are taken from the address book (NAMES
file) of the source, this ID is likely known by many of the victims.

Another example is the re-shrink-wrapped software of a reputable vendor on
the shelf of a naive or irresponsible distributor.   Many of us are
likely to be duped into executing such software.   How can we know that
the software is what the vendor shipped?  How can the vendor
demonstrate, even to his own satisfaction, that he did not ship it?

Digital signatures (which are not simply CRCs) provide at least a
partial answer to these questions.  They provide compelling evidence
that a data object originated in a particular place and that they have
not been contaminated since leaving that point.

They do not and cannot protect us against all lies and all malice.  They
may not protect us at all if we refuse to apply them or reconcile them.
However, they make it possible to protect the innocent.  If we refuse to
accept data objects that are not signed by the source, then they will
help to fix accountability for malice.  In the presence of such
accountability the quantity of malice can be expected to be less than it
would be the absence of such signatures.

Finally, the ability of a virus to spread in a population, as opposed to
its ability to detect and bypass the controls in a member of the
population, depends upon there being exploitable similarities among the
members of the population.   The insistence of Mr. Radai et. al. that,
since it is possible to detect and bypass any control, that all is
futile does not stand up.  By subtle changes to my machine and its use,
I can make it sufficiently different from the population at large, to
make it effectively immune from practical attacks.  If we were all doing
that, viruses would be far less successful.  That I cannot make it
theoretically resistant to hypothetical attacks, may be of little
interest.

It is time to stop condemning the useful out of hand.  Those who insist
upon doing so are contributing to the problem rather than the solution.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Sun, 10 Dec 89 18:10:00 -0500
From:    someone please stop the bunny <[e-mail]>
Subject: JUST WHAT IS *LSD? (Mac)

    The recent notification of the WDEF virus residing in the Desktop
got me thinking so I poked through our fileserver's desktop with
resedit.  I found a resource that began with a diamond and followed up
with LSD sort or *LSD but with a diamond instead of a star.  Does
anybody know what this is?
                                   - Zav
 ________________________________________________________        `!'
|   - Southeastern Massachusetts University U S of A -  |
| Live From the 'REAL' SMU... iiiiiiit's Alex!          |      _-----_
| alias Alex Zavatone, RoadHazard (I've earned that one)|     /  _ _  \
| Discmaimer?!: You must be kidding                     |     |  O o  |
|--------------------------------------------------------     |   v   |
| Bitnet -> ACSAZ@SEMASSU | ACS - It's not just a job |       \ '___` /
| Hepnet -> ALEX@SMUHEP   |       It's an Adventure!  |        | \_/ |
|_________________________|___________________________|         \___/

------------------------------

Date:    Sun, 10 Dec 89 15:53:12 -0800
From:    [e-mail]
Subject: SCANV51 (PC)

        SCANV51 is now available on HomeBase.  It checks for the
Datacrime II-B, the Payday and the Amstrad viruses as new additions to
the list.  The Datacrime II-B and Payday viruses were submitted by Jan
Terpstra of IBM in the Netherlands and the Amstrad was submitted by
Jean Luz of the University of Lisbon in Portugal.  All three are
described in the VIRLIST.TXT file included with SCAN.
        Five new viruses (at least new to McAfee and the HomeBase
group) have been submitted by Andrzej Kadlof, an editor of KOMPUTER
Magazine in Warsaw, Poland.  These viruses have been reported in the
public domain within Poland and many other Eastern block countries,
according to Kadlof, but we are not aware of any reports from Western
Europe or the U.S.  David Chess at IBM has been given copies as has
Joe Hirst in London to determine whether these are indeed new viruses.
In any case, they are new to SCAN and will be included in the next
release.  Two are EXE and COM infectors and three are just COM
infectors.  Hopefully I can report details of how they work within a
few days.

Alan

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 12 Dec 1989    Volume 2 : Issue 258

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

WDEF virus questions (Mac)
new anti-virals (IBMPC)
Re: WDEF Virus (Mac)
Poland Viruses/Oropax (PC)
Experimental one-way hash function

---------------------------------------------------------------------------

Date:    11 Dec 89 08:56:28 +0000
From:    [e-mail] (MATS LEJON)
Subject: WDEF virus questions (Mac)

In the message WDEF Virus Alert (MAC) John Norstad writes

>Unfortunately, the virus manages to avoid detection by all of the
>popular protection INITs, including Vaccine 1.0.1, GateKeeper
>1.1.1, SAM Intercept 1.10, and Virex INIT 1.12.

What about the RWatcher INIT? It would be no problem to configure it
to look for a WDEF resource, but this would of course be of no use
if the WDEF virus uses a system call to propagate whitch RWatcher
does not watch for. Does anyone have any more info about the virus,
its size for example, or how it is possible that a resource with the name
WDEF gets executed, I guess it must contain executable code to
propagate itself?

                   Mats Lejon, Chalmers Univ. Tech. Sweden.

------------------------------

Date:    Mon, 11 Dec 89 11:43:26 -0600
From:    [e-mail] (Jim Wright)
Subject: new anti-virals (IBMPC)

Recent submissions for the IBMPC anti-viral archives sent to me.

killer.arc      Detects and removes Stoned virus
        No source code, no documentation, author unknown.  Use
        at your own risk.

pill.arc        Detects and removes Stoned virus
        No source code, no documentation, author unknown.  Use
        at your own risk.  I have included a rudimentary disassembly
        for your viewing pleasure.

vkill10.arc     Detects and removes Jerusalem virus
        Source (TurboC) for program to detect and remove Jerusalem
        virus.  No separate docs provided--read the code.  No
        executable provided.

Jim

------------------------------

Date:    Mon, 11 Dec 89 11:25:26 -0800
From:    [e-mail]
Subject: Re: WDEF Virus (Mac)

> "Jeff Shulman, the author of Virus Detective 3.1, recommends adding the
> following search string to detect the virus:
>
> CREATOR=ERIK & Resource WDEF & Any
>
> Virus Detective can also be used to remove the virus ......"
>
> Where or to what do we add the "following search string".  Please
> pardon my ignorance.

Assuming that you have a relatively recent version of VirusDetective,
you can open the desk accessory, click the "Modify Search Strings"
button (or enter command-M), type the above string into the one-line
field near the bottom of the search-string dialog box, click the "Add"
button to add the string to the working search criteria, and then
click the "Save" button to record the new criteria in the desk
accessory's long-term memory (in the System file).

You can then search disks, or individual Desktop files, using the
buttons in the desk accessory's main window.

If you're hunting for the WDEF virus, you should _not_ do so under
MultiFinder... run in the "uni-Finder" environment, launch an
application program (almost any will do), and then invoke
VirusDetective from within that application.  You should _not_ be
running the Finder (multi- or uni-) if you wish to remove the WDEF
virus from your Desktop file.

Disinfectant 1.4 is now available, by the way... it, also, can find
and eliminate WDEF.
- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    Mon, 11 Dec 89 08:56:54 -0800
From:    [e-mail]
Subject: Poland Viruses/Oropax (PC)

        One of the five viruses submitted to McAfee by Andrzej Kadlof
appears to be the long-lost Oropax virus, at least according to Dave
Chess at IBM.  The virus matches the original descriptions exactly,
including length, infection mechanism, self identification technique,
host class and activation function. The Homebase group has always
considered the virus to be either extinct or a hoax, but Kadlof
insists it is active and common in the Eastern Bloc.  If this is true,
then it raises some interesting points about the epidemiology of
computer viruses.  How for example, can the Ping Pong virus be common
in Austria, but unknown in Checkoslovakia, a{nd the Oropax be common
in Checkoslovakia but unknown in Austria, while the Jerusalem is
rampant in both countries? (These two countries do, I Believe, share a
common border - if not forgive my geographic ignorance).
        Any information about the occurance of the Oropax in Europe or
the U.S. would be appreciated by the way.
Alan

------------------------------

Date:    11 Dec 89 11:36:35 -0800
From:    [e-mail]
Subject: Experimental one-way hash function

The one-way hash function, Snefru version 2.0, has been released for
general use.  It generates either a 128 bit or 256 bit output.

Previous discussions in this group have mentioned the X9.9 MAC
(Message Authentication Code) that involves a secret key.  Snefru is a
one-way hash function, and therefore does not use or require any
secret information.  Further, Snefru has substantially better
performance than any DES based system.

One-way hash functions have the property that it is computationally
infeasible to find two inputs that produce the same output.  Thus, if
I can authenticate the (128 or 256 bit) output, then I can
authenticate the large (perhaps megabytes) input that produced that
output.

The method of authenticating the output and the method of insuring the
integrity of the program computing the one-way hash function are
separate issues, not addressed by Snefru.

The C source for Snefru version 2.0 is available to anyone who wants a
copy via anonymous FTP from "arisia.xerox.com" (a Unix system at Xerox
PARC in Palo Alto, CA) in directory "/pub/hash".  The source files
are: hash2.0.c, standardSBoxes2.c, and testSBoxes.c.

An assembly language version written for the Sun SPARCstation 1 can
hash large files at a speed slightly faster than 8 megabits per
second.  This includes CPU time (as measured by the "time" command)
and excludes disk transfer time etc.

Snefru version 2.0 is still preliminary.  It has received only modest
security review.  It would seem prudent to use it only for
experimental or research purposes until it has received more
widespread scrutiny.  A significant purpose of this posting is to
invite such scrutiny.

     Cheers!
       Ralph C. Merkle
       Xerox PARC
       3333 Coyote Hill Road
       Palo Alto, CA 94304
       [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 13 Dec 1989    Volume 2 : Issue 259

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Preventative measure for DIR exec (VM/CMS)
AIDS Disk sent in UK
Wdef at UKCC (Mac)
re: Poland Viruses/Oropax (PC)
Re: Seeking Gatekeeper (Mac)
Never say die
Major Trojan Warning (PC)
Update on AIDS Trojan (PC)
Yet Another EAGLE Appears (PC)

---------------------------------------------------------------------------

Date:    Tue, 12 Dec 89 09:58:06 -0500
From:    Lee Miller (Gonzo) <[e-mail]>
Subject: Preventative measure for DIR exec (VM/CMS)

  Just a suggestion but anyone who wants to take an extra
precautionary measure towards the dir exec or any virus erasing files
meeting certain time date criteria could use the touch exec and module
available from the listserver at BLEKUL11 to change the time date of
your files. Thus before running any exec that you don't know what it
it you change all time dates to before 1990 so the deletion that dir
does wont find anything to erase. If you have any inquiries to this
exec e-mail me.
                                     Lee Miller
                                     [e-mail]

------------------------------

Date:    Tue, 12 Dec 89 14:53:34 +0000
From:    Alan Jay <[e-mail]>
Subject: AIDS Disk sent in UK

                        AIDS DISK -- PC Cyborg Corporation

This disk was mailed to many people on a major magazine mailing list today
12-DEC-1989.

If you recived a copy DO **NOT** RUN it -- We do NOT know what it does.

This disk implies that it may cause harm to your PC -- DO NOT RUN IT!!!!


If you have run it -- DO NOT PANIC!!!!

Currently we have NO proof that the disk is harmful.

DO NOT RUN THE PROGRAM AGAIN.

The program renames your "autoexec.bat" so you will have to reconstitute your
old one.  "Autoexec.bat" has been hidden by setting the 'hidden' attribute
you may need NORTON or similar to delete the new "Autoexec.bat".

There are also a number of other hidden subdirectories.

Currently we do not kenow the purpose of this disk and so can not say what
damage that it may do, if any, or what you should do about it.

Warn other users not to run the program.

Currently the only 100% safe course of action is to boot of the original
DOS system disk and perfrm a reformat of your disk -- We DO NOT recommend
you do this unless you have a recent backup that you are happy with --
We have no proof of any malicious nature in this disk.

We hope to update this bulletin later today or tomorrow as more information
becomes available.

[Ed. See more information below.]

Alan Jay @ The IBM PC User Group, PO Box 360, Harrow HA1 4LQ ENGLAND
Phone:  [phone]                        Email:  [e-mail]
Path:   ...!ukc!slxsys!ibmpcug!alanj            Fax: [phone]
Disclaimer: All statements made in good faith for information only.

------------------------------

Date:    Mon, 11 Dec 89 17:28:00 -0500
From:    someone please stop the bunny <[e-mail]>
Subject: Wdef at UKCC (Mac)

    Guess what?!  I just talked to someone at UKCC (University of
Kentucky) with a finder slowdown problem.  He checked and it was WDEF.
So now we have another site for WDEF infection.  To date Southeastern
Mass U is clean (of WDEF that is).  This is not nice.  Anyone know
where this one came from?
                                   - Zav
                            "ACS - Never a dull moment"

------------------------------

Date:    12 Dec 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Poland Viruses/Oropax (PC)

[e-mail]:

>         One of the five viruses submitted to McAfee by Andrzej Kadlof
> appears to be the long-lost Oropax virus, at least according to Dave
> Chess at IBM.

Just to be as timid as possible, I didn't say "this is the Oropax
virus"; I said "this seems to match the description of the 'Oropax'
given in the MSDOSVIR.A89 document from Hamburg".  For all I know,
this is a brand-new virus, written by some unimaginative virus author
who heard the Oropax rumors, and decided it was a good idea!  *8)

DC

------------------------------

Date:    Mon, 11 Dec 89 19:41:41 -0700
From:    Ben Goren <[e-mail]>
Subject: Re: Seeking Gatekeeper (Mac)

Thanks to all those who replied.  Here's a summary of what people reccomended:

Gatekeeper is avaible

1) through the Info-Mac archives.  These can be accesed (as I did) through
   Macserve (tell Macserve at PUCC help for instructions) or FTP at
   sumex-aim.stanford.edu or Rice University (I no longer have their
   complete address).  There also is a relay in Ireland, and I believe others;

2) through FTP at Simtel-20.

3) through many individuals, including myself, if all else fails.  Just ask!

The Info-Mac archives have several other virus protection programs, as well as
a large collection of other free-, shareware, and public domain files.  I
imagine that Simtel-20 also has a similar collection, if it is not another
copy of Info-Mac.

Now, one more question:  is there a complete list of resources one shoul
configure VirusDetective with?

Thanks again,

..............................................................
Ben Goren                              T T T        /
Trumpet Performance Major       )------+-+-+--====*0
Arizona State University           ( --|-| |---)
Bitnet:  AUBXG@ASUACAD               --+-+-+--
..............................................................

------------------------------

Date:    Thu, 07 Dec 89 21:42:23 -0800
From:    [e-mail]
Subject: Never say die

Virus Immortality

   There is a growing trend, not just in portable computers, to save
the state of the machine when the computer is "turned off".

   This is a consideration for fault-tolerant or semi-fault-tolerant
systems, where there has been great attention paid to saving all
files and system state no matter what, but probably these system
administrators will be knowledgeable enough to work through the
problems created by system design.

   There will, however, be users who don't understand what is
happening when they put a computer to sleep or turn it off, or even
remove the battery.  In some cases, even removal of the power supply
(battery) does not kill the contents of RAM due to a "keep-alive"
smaller battery backup.

   Leaving aside the other security implications of always
preserving RAM, (such as password retention or decrypted file
retention) virus detection and removal will certainly be more
confusing.

   In other words, the current practice of telling computer users to
be sure their machine has been turned off during virus removal will
no longer be sufficient.  Even the people who think they are being
extra careful by removing the battery for a minute or two will be
fooled.

   Cases in point:

   1. Macintosh Portable.  The normal "off" mode is really a sleep
      mode, with all RAM contents retained.  At the touch of a key,
      the user is able to continue with any operations in progress
      at the time the machine was left.  The running program (s) are
      still running, data files open, etc.  Removal of the main
      battery will not erase RAM due to a 9 volt backup, designed to
      ensure continuity during battery switches.
         According to an Apple representative, use of the reset
      switch (not the interrupt) will force an immediate power-off
      to RAM, and a start-up with clean RAM.

   2. Zenith MinisPort.  Part of RAM can be configured as a non-
      volatile RAM disk.  A number of other machines have this
      feature also. This shouldn't cause as much problem, since
      people are used to permanent storage on disks and know that
      it needs to be checked and purged.  Extra RAM can also be
      configured as EMS memory, probably also non-volatile.

   3  Poqet pocket MS-DOS PC.  Memory is powered all the time.  Even
      when the batteries are changed, a capacitor will keep the
      system going for 10 to 15 minutes.  The keyboard I/O "on/off"
      switch merely puts the machine to sleep.  There is a recessed
      reset button which will purge RAM.

   4  Toshiba portables.  New portables, such as the T1000SE, have
      an "auto-resume" feature to allow the computer to be turned
      "off", including changing the battery, while RAM contents are
      preserved.

   5  Emerson Accucard.  This is an IBM PC hardware card with its
      own battery.  It is designed to detect a power failure, and
      save the state of the machine to disk before shutting down.
      When I called both the company and their national distributor,
      nobody could tell me whether there was any way to defeat this
      system, such as cold booting from a floppy disk, without
      physically removing the card.  They promised to call back with
      more information.

------------------------------

Date:    Tue, 12 Dec 89 11:26:29 -0800
From:    [e-mail]
Subject: Major Trojan Warning (PC)

This is an urgent forward from John McAfee:

     A distribution diskette from a corporation calling itself
PC Cyborg has been widely distributed to major corporations and
PC user groups around the world and the diskette contains a
highly destructive trojan.  The Chase Manhattan Bank and ICL
Computers were the first to report problems with the software.
All systems that ran the enclosed programs had all data on the
hard disks destroyed.  Hundreds of systems were affected.
Other reports have come in from user groups, small businesses and
individuals with similar problems.  The professionally prepared
documentation that comes with the diskette  purports that the
software provides a data base of AIDS information.  The flyer
heading reads - "AIDS Information - An Introductory Diskette".
The license agreement on the back of the same flyer reads:

"In case of breach of license, PC Cyborg Corporation reserves the
right to use program mechanisms to ensure termination of the use
of these programs.  These program mechanisms will adversely
affect other program applications on microcomputers.  You are
hereby advised of the most serious consequences of your failure
to abide by the terms of this license agreement."

Further in the license is the sentence: "Warning:  Do not use
these programs unless you are prepared to pay for them".

If the software is installed using the included INSTALL program,
the first thing that the program does is print out an invoice
for the software.  Then, whenever the system is re-booted, or
powered down and then re-booted from the hard disk, the system
self destructs.

Whoever has perpetrated this monstrosity has gone to a great deal
of time, and more expense, and they have clearly perpetrated the
largest single targeting of destructive code yet reported.  The
mailings are professionally done, and the style of the mailing
labels indicate the lists were purchased from professional
mailing organizations.  The estimated costs for printing,
diskette, label and mailing is over $3.00 per package.  The
volume of reports imply that many thousands may have been mailed.
In addition, the British magazine "PC Business World" has
included a copy of the diskette with its most recent publication
- - another expensive avenue of distribution.  The only indication
of who the perpetrator(s) may be is the address on the invoice to
which they ask that $378.00 be mailed:

          PC Cyborg Corporation
          P.O. Box 871744
          Panama 7, Panama

Needless to say, a check for a registered PC Cyborg Corporation
in Panama turned up negative.

An additional note of interest in the license section reads:
"PC Cyborg Corporation does not authorize you to distribute or
use these programs in the United States of America.  If you have
any doubt about your willingness or ability to meet the terms of
this license agreement or if you are not prepared to pay all
amounts due to PC Cyborg Corporation, then do not use these
programs".


John McAfee

------------------------------

Date:    Tue, 12 Dec 89 18:17:04 -0800
From:    [e-mail]
Subject: Update on AIDS Trojan (PC)

The following is a posting from John McAfee:

        Early reports from people who have disassembled the AIDS
trojan that has been mailed to numerous European corporations indicate
that the trojan may be encrypting information on the disk rather than
destroying it outright.  The results are the same without a decrypting
routine but the possibility is] now raised that the perpetrators do
have and may offer such a decryptor.  The report from Chase Manhattan
Bank that the name and address in the Trojan are bogus may not be
correct.  John Markoff of the New York Times has since stated that his
sources found a real corporation corresponding to the name and address
in the file.  This raises some interesting questions which, I believe,
only time will answer.  Whatever is happening, this much is known: The
trojan will make all data on the hard disk unusable; the change
happens suddenly; and no recovery is yet known.  If you find or have a
copy of this diskette don't use it.

John McAfee

------------------------------

Date:    Tue, 12 Dec 89 18:09:00 -0500
From:    IA96000 <[e-mail]>
Subject: Yet Another EAGLE Appears (PC)

At 03:00 yesterday another version of EAGLE.EXE was discovered and
forwarded to SWE for analysis. Here are the results.

See back issues of VIRUS-L and/or VALERT-L for original symptoms.

This new version has changed slightly:

1) Contains Jerusalem-D virus. Active and spreads!

2) Seeks out and overwrites the following files and locations:

   a) COMMAND.COM (ascii 246 used to overwrite)
   b) BOTH FAT's  (ascii 246 used to overwrite)
   c) BOOT SECTOR (ascii 246 used to overwrite)
   d) EAGLSCAN.EXE (string "F**K YOU" used to overwrite)
   e) SCAN.EXE     (string "F**K YOU" used to overwrite)
   f) VIRUSCAN.EXE ( same as last two above used to overwrite)

3) There seems to be a built in timer. Once the file has been loaded
   it remains dormant for twenty minutes. During this time the VIRUS
   can be detected by SCAN.EXE if you use the /M switch. Once the timer
   has run down, the trojan takes over and does its dirty deed.

4) Unlike previous versions, it DOES NOT matter if the disk is a
   DOS system disk or not. If a file is not found, it just continues
   on down the list. Previously COMMAND.COM had to be in the root to
   trigger the trojan.

5) SWE reports that they feel this WAS NOT written by the same author(s)
   as the first two versions. First, this new version appears to be
   written in Pascal. Second, SCAN.EXE will identify the file. It has
   not been encrypted or compressed like the previous versions.

Since SCAN.EXE will detect the virus, and since SWE is closing for their
vacation period, they feel there is NO rush to update EAGLSCAN at this
time. They said it will be done when they get back.

One important point needs to be repeated! SCAN.EXE will identify the
virus, in memory when you use the /M switch. It will also detect the
virus in a file. It has no way of knowing if the file also contains a
trojan (understandable, it wasn't designed to) so be wary if you
decide to experiment with this new version of EAGLE.EXE!!!!

Thanks to Harriman, New York for sending it for evaluation.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 14 Dec 1989    Volume 2 : Issue 260

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

New Virus Encyclopedia (Mac)
File authentication software (PC)
re: Preventative measure for DIR exec? (VM/CMS)
RE: AIDS Trojan (PC)
Becoming a Virus Expert (Mac)
Re: AIDS DISK UPDATE (I)
1813 Virus Info Needed (PC)
Re: AIDS -- UPDATE II -- What can you do.
AIDS Trojan Update (PC)
WDEF found at SUNY-Binghamton (Mac)

---------------------------------------------------------------------------

Date:    Wed, 13 Dec 89 04:01:26 +0000
From:    [e-mail] (Henry C. Schmitt)
Subject: New Virus Encyclopedia (Mac)

This is to announce a new version of Virus Encyclopedia.  I have updated
the stack to include the WDEF Virus and all those variants of nVIR that
have appeared since its last release.  Which release you have can be
determined by the date modified listed on the Disclaimer card.  This
latest release is dated 12/12/89.

I have just finished uploading VE to CompuServe, GEnie, several Chicago
BBSs, and HomeBase BBS in California.  I have also made arrangements
with John Norstad to get a copy to the info-mac archives and
comp.binaries.mac.  If you are unable to get the stack in any other way
(and please try!), I will accept requests accompanied by a disk or
$2.50 at:

                Henry C. Schmitt
                6613 Scott Lane - Apt. 17
                Hanover Park, IL 60103-3849

I'll send back a copy of the NorthWest of Us Virus Control disk which
includes VE, as well as the best of the virus control programs.

                        Henry C. Schmitt
                        Author of Virus Encyclopedia
- --
  H3nry C. Schmitt     | CompuServe: 72275,1456  (Rarely)
                       | GEnie: H.Schmitt  (Occasionally)
 Royal Inn of Yoruba   | UUCP: [e-mail]  (Best Bet)

------------------------------

Date:    Tue, 12 Dec 89 17:40:00 -0500
From:    IA96000 <[e-mail]>
Subject: File authentication software (PC)

Recently I had the chance to discuss the inner workings of VALIDATE.EXE,
(no..not VALIDATE.COM), with the authors. This program has been around
for almost two years now, and has just under gone a dramatic change.

In the past, it has detected changes in a file by reading the entire
file, and using two proprietary formulas, calculated two CRC's for
each file tested. VALIDATE.EXE is fast and capable of processing
over 64,000 characters a second.

The new version takes an entirely different approach. While I cannot
go into intimate detail, basically it reads in large blocks of the
file, takes a "snapshot" and continues. The block size varies depending
on file size and available memory. If EMS or Extended memory is detected
the program will increase the size of the blocks being read, up to the
optimal size of a 1 megabyte block.

Each "snapshot" taken is then processed. The contents of "snaphots"
vary, depending on the type of file being processed (com, exe, ascii),
the size of the file, and several other factors, including the total
number of snapshots taken.

As processing continues, two authentication strings are built. These
are then encrypted, and converted to hex format for display.

There are two versions of this program. The DOS version is capable of
reading and processing over 113,000 characters a second.The OS/2
version of validate was designed to run under PM and takes full
advantage of the advanced OS/2 functions. It has the ability to run
several threads at the same time and does so whenever possible. The
raw processing speed of the OS/2 version is not as fast as the DOS
version, but the use of threads speeds the entire program up. Just
thought you might like to know about this program. It will be available
in both versions through SIMTEL in the near future.

I have been asked to pass the following message along verbatim:

Start of message =================

From: SWE
  To: VIRUS-L Subscribers
  Re: Free disk offer

     After processing and filling requests for over 570 EAGLSCAN (tm)
disks, we are now withdrawing our offer. Each and every request has
been filled, and all disks are on the back via US mail.

     SWE did not expect any where near the response we received and
it has been a major project to produce these disks for you. So be it,
we made the offer, and we learned our lesson.

     Any disks received after December 13, will not be processed until
we open again, after the holidays. We will fill any requests starting
January 4, when we return from holiday.

     Thank you for your requests and have a happy holiday.

End of message ===============

------------------------------

Date:    13 Dec 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Preventative measure for DIR exec? (VM/CMS)

Lee Miller (Gonzo) <[e-mail]> writes:
>                                ... could use the touch exec and module
> available from the listserver at BLEKUL11 to change the time date of
> your files...
> Thus before running any exec that you don't know what it
> it you change all time dates to before 1990 so the deletion that dir
> does wont find anything to erase.

I think this is based on a misunderstanding of the damage that
the DIR EXEC does.   It never looks at the dates on *files*;
it looks at the current date (via QUERY TIME), and if the last
two digits of the year are greater than 89, it will erase all
files with mode a0 or a1, regardless of the dates on the files.
Changing dates on files will have no effect on how DIR behaves.

DC

------------------------------

Date:    Wed, 13 Dec 89 09:11:26 -0500
From:    [e-mail] (David Gursky)
Subject: RE: AIDS Trojan (PC)

The AIDS Trojan Horse discussed by Alan Jay and John McAfee raises some
interesting questions about accountability.

Ignoring the issue that it is unlikely that the U.S. Government is
unlikely to get cooperation from the Panamanian authorities in
apprehending the culprits and bringing them to trial in either
country, could the perpetrators be held liable under U.S. law for
damages, when the licensing notice clearly states the program is not
licensed to be used in the United States, and that damage will result
if you attempt to do so.

In the broader case, could the perpetrators be extradicted to one of
the European countries that have better relations with Panama, and be
held liable for damages even though the license says not to use the
application without first paying for it.

One consequence of this attack (although I find it unlikely legal
authorities will be able to take advantage of it because of the
situation in Panama) is that the perpetrators should be relatively
easy to track.  Someone rented the Post Office box in Panama.
Hopefully someone is picking up the mail from that box, and from there
it goes to the people behind it, somehow.

------------------------------

Date:    Wed, 13 Dec 89 10:09:49 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Becoming a Virus Expert (Mac)

Earlier in the year (mid to late October) someone inquired on some
suggestions for becoming a "virus expert".  (I assume in hopes to
become an anti-virus expert.)  Joe MacMahon suggested a number of
things one of which included reading about ROM patches, INITs, and VBL
tasks in Inside Macintosh.  I made an attempt to locate these topics
in Inside Macintosh and came up with the table below.  (I was unable
to find any information in the index on ROM Patches.)  I have not read
the topics I have listed, but intend make reading them a priority.
Are what I have listed below relevant to the person who wants to
maximize the amount of information attained while minimizing material
to be studied?  Are there other references that would be better?
(Inside Macintosh references and "outside" references.)  Other
thoughts and comments are most welcome.  I hope this helps some and
hope that others will help this list get "fine-tuned".  If you find
anything grossly wrong with the list please do not bug flame Joe,
flame me.  Thanks.

Greg

Topic                      Volume    Pages
- -----                      ------    -----

Inits                         I      114-115
InitGraf                      I      162-164
Font Manager Routines         I      222-227
Window Manager                I      280-288
Dialog Manager                I      410-423
Memory Manager               II        3- 52
Vertical Retrace             II      349-354
Parameter RAM Operations     II      380-382
The Video Interface         III       18- 20
Resource Manager              V*      29- 38

- ---------------------------------------------
* - Sorry don't have access to Volume IV.

Greg

Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]
Acknowledge-To: <C0195@UNIVSCVM>


------------------------------

Date:    Wed, 13 Dec 89 16:09:36 +0000
From:    Alan Jay <[e-mail]>
Subject: Re: AIDS DISK UPDATE (I)

                        AIDS INFORMATION DISK
                        =====================


The latest on this is as follows:

If you have run this disk contact ROBERT WALCZY at PC Business World
on 01-831 9252 they have a FREE disk that combats the effects of the
disk and they will send a copy to users effected.

Either call Robert of FAX him on 01-405 2347 with your name and address.

The disk should be available in the next day or two.

The program will be available on CONNECT (01-863 6646) for download as
soon as it has been tested.


=======================================================================


The AIDS disk when installed creates a number of hidden files and
directories.  You can remove these files by running the program
mentioned above or by using the Norton Utilities, PC Tools or equivalent
program.

The files that are hidden include a new AUTOEXEC.BAT and a number of
other files and directories that contain characters that can not be
accessed by standard DOS commands.  You will need to rename the files/
directories before they can be deleted.


This information will be updated as we learn more about the disk.


Alan Jay -- The IBM PC User Group -- 01-863 1191.

------------------------------

Date:    13 Dec 89 15:40:48 +0000
From:    [e-mail]
Subject: 1813 Virus Info Needed (PC)

I have encountered the virus 1813 here at my school.  Does anyone out
there know anything about this virus.  This was detected using the
Virscan program by IBM.  I think this virus may be related to the
"Friday the 13th" virus.  Any comment out there.  Please post in the
news group since some people may be interested.  Thanks

Doug

------------------------------

Date:    Wed, 13 Dec 89 18:26:57 +0000
From:    Alan Jay <[e-mail]>
Subject: Re: AIDS -- UPDATE II -- What can you do.

                                AIDS INFORMATION DISK
                                =====================

Update 2  13-Dec-1989 6pm

IF you have not run this disk DO NOT INSTALL it appears to be a very
cleverly written TROJAN program that can be activated by a number of
methods.  Currently the activation method that has been detected uses
a counter of the number of system reboots.  When the counter gets to
90 the system goes into a second phase and encrypts files and
directories on your hard disk.

The program appears to have a number of embelisments that makes one
think that the front door we have been shown MAY not be the only
method that the system uses for deciding when to activate.  This
is a very nasty program and the only 100% safe thing to do is to
backup all DATA files and perform a full reformat of your hard disk.

Followed by a reinstallation of all DATA, from your backup, and
programs from original system disks (or backup prior to installing
this software).

This should only be attempeted once at least TWO copies of all
valuable data have been extracted from the system.  Please remember to
boot your system off an original DOS disk before starting this
procedure.

Full details of the suggested procedure will be posted tomorrow.

Alan Jay

Readers who do not wish to follow this route may be interested to
in the folowing information about the primary activation system.

1)  A hidden 'ACTOEXEC.BAT' file contains

CD \<ALT255>
REM<ALT255>

        it then runs your AUTOEXEC.BAT which the program renamed AUTO.BAT

2) A hidden subdirectory <ALT255> contains a file REM<ALT255>.EXE

Each time the system is booted the program is run and the counter
incremented/decremented.  After 90 activations the system enters phase
TWO.

Please note that the system uses the <ALT255> character 'hi space' in the
file names to stop standard DOS procedures acting on these files.


IT MAY be possible to delete these entries and thereby disable the
program this is NOT certain and it will take several months to discover
if this is a safe course of events to take.

I hope that this information helps.  I also understand that this is in the
hands of the Fraud Squad / Computer Crime Division of the Metropolitan
Police.  If you have any further information I am sure that they would
be interested to here from you.


Alan Jay -- IBM PC User Group -  01-863 1191

------------------------------

Date:    Wed, 13 Dec 89 16:58:52 -0800
From:    [e-mail]
Subject: AIDS Trojan Update (PC)

This is a forward from John McAfee:

     A lot more has been discovered about the AIDS Information
Trojan in the past 24 hours.  First, the diskette does not
contain a virus.  The install program does initiate a counter,
and based on a seemingly random number of re-boots, the trojan
will activate and destroy all data on the hard disk.  The
diskette was mailed to at least 7,000 corporations, based on
information obtained from CW communications - one of the magazine
mailing label houses used by the perpetrators.  The perpetrator's
initial investment in disks, printing and mailing is well in
excess of $158,000 according to a Chase Manhattan Bank estimate
that was quoted in a PC Business World press release from
London.  The bogus company that sent the diskettes had rented
office space in Bond Street in London under the name of Ketema
and Associates.  The perpetrators told the magazine label
companies that they contacted that they were preparing an
advertising mailer for a commercial software package from
Nigeria.  All offices had been vacated at the time of the
mailing, and all addresses in the software and documentation are
bogus.
     The Trojan creates several hidden subdirectories -- made up
of space and ASCII 255's  -- in the root of drive C.  The install
program is copied into one of these and named REM.EXE.  The
user's original AUTOEXEC.BAT file is copied to a file called
AUTO.BAT.  The first line of this file reads -- "REM Use this
file in place of AUTOEXEC.BAT for convenience".  The installation
also creates a hidden AUTOEXEC.BAT file that contains the
commands:

          C:
          CD \
          REM  Use this file in place of AUTOEXEC.BAT
          AUTO

     The CD \ actually contains ASCII characters 255, which
causes the directory to change to one of the hidden directories
containing the REM.EXE file.  The REM file is then executed and
decrements a counter at each reboot.   After a random number of
reboots, the hard disk is wiped clean.  Definitely a new
approach.
     So far the mailings appear to be limited to western Europe.
No reports have been received from the U.S.  If anyone does have
the diskette, or has already run the install program, a
disinfector has been written by Jim Bates and is available on
HomeBase for free download.  408 988 4004.  The name of the
disinfector is AIDSOUT.COM.

John McAfee

------------------------------

Date:    14 Dec 89 03:13:50 +0000
From:    [e-mail]
Subject: WDEF found at SUNY-Binghamton (Mac)

        We have identified the WDEF virus here in our public complexes
here at SUNY-Binghmton.  Thanks to Disinfectant 1.4, we are already
asking all users to come to our consulting office and have their disks
checked.

        The earliest date of infection that we have noticed in our
work tonight is December 11, 1989; indicating that it spread extremely
rapidly here, possibly due to a pair of infected printing stations
that we found.

        Over the last eight hours, the number of infected disks found
has been dropping rapidly, indicating that we caught it before it got
too far.

        Many, many thanks to comp.virus for the alerts, and to John
Norstad for his quick work with Disinfectant!

                                                - Ken

- -------------------------------------------------------------------------
Ken Hoover [ [e-mail] | [e-mail] ]
     Resident computer jock and Mac hacker, SUNY-Binghamton Bio dept.
     Senior undergraduate consultant, SUNY-Binghamton Computer Center
- -------------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 18 Dec 1989    Volume 2 : Issue 261

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

re: 1813 Virus Info Needed (PC)
Aids disk information (PC)
Re AIDS disk (PC)
What does the WDEF virus do? (Mac)
Re: Update on AIDS Trojan (PC)
Disinfectant 1.5 (Mac)
WDEF found at University of Vermont (Mac)
AIDS TROJAN (PC)
Gatekeeper Aid 1.0 Released (Mac)

---------------------------------------------------------------------------

Date:    14 Dec 89 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: 1813 Virus Info Needed (PC)

The 1813 virus is the same virus that is commonly called "the
Jerusalem virus".  It is the most widespread of a number that
activate on Friday the 13th, so it's sometimes called the
"Friday the 13th" virus.   That's not a very good name, though,
since there's more than one virus that it fits.   Stick with
"1813" or "Jerusalem"!   *8)              DC

------------------------------

Date:    Thu, 14 Dec 89 11:14:39 +0000
From:    Alan Jay <[e-mail]>
Subject: AIDS disk information (PC)

The following, written by Alan Solomon, gives details of the AIDS
Information Disk sent out by PC-CYBORG and gives a method for
restoring your disk to its former state.  Remember if you have not run
this disk DO NOT run it.

This information is believed to be correct BUT the program appears to be
very clever and therefore we suggest that you must be very careful in
carring out any of the followig instructions.

Alan Jay  -- IBM PC User Group -- 01-863 1191


PRELIMINARY INFORMATION ON THE "AIDS" DISKETTE FROM PC
CYBORG CORPORATION.

This is bulletin number AS/3


You will probably have read in the press about the AIDS diskette, a
diskette that was mailed out to a great subscribers to PC Business
World (through absolutely no fault of the magazine's).  This diskette
is a trojan - DO NOT RUN IT.

It is a diskette that was sent through the post, unsolicited, and
claiming to be a program that gave you useful information about the
AIDS disease.  The accompanying licence was abit suspicious, so many
people didn't run it (it threatened to do dire things to your computer
if you didn't pay for the software).

We've done a preliminary analysis on it, and it works like this.  If
you run the INSTALL program, it creates two subdirectories with
"impossible" names on the hard disk - one of these has a one-character
name, and that character is [Alt-255] (hexadecimal FF).  In that
subdirectory , it puts a program called REM[Alt-255] .EXE.  The
[Alt-255] character is invisible.  It copies your AUTOEXEC to a file
called AUTO.BAT, and puts an Echo off and a REM statement in front.
It creates a new AUTOEXEC.BAT file, and makes it hidden and readonly.
In that AUTOEXEC, it does a "CD \[Alt255]" and then "REM[Alt-255]"
followed by a plausible-looking remark.

After you run the AUTOEXEC, and therefore the REM [Alt-255] program, a
number of times (we triggered it with 90, but this is only a
preliminary result, and it may be triggerable with fewer or more), the
damage routine is triggered.  This would usually happen when the
machine has been booted that many times.  A series of messages are put
up on the screen, aimed at persuading you not to switch off, and the
trojan then encrypts your directory and makes all the files hidden
except one called CYBORG.DOC.

If you then boot from the hard disk, it tells you that a software
licence has expired, and tells you to renew it - another request for
money.  If you do a Ctrl-Alt-Del, it fakes a reboot, and pretends to
be running the Dos prompt - actually, a program is now running which
fakes Dos.  If you do a DIR, it shows you the unencrypted filenames,
followed by a warning not to use the computer.  it tells you that you
must renew the lease in the software.  Any other command, it also
fakes a response to, and shows you the same message.

It also has a routine that could be called the SHARE routine.  When
this runs, it tells you that you can have 30 more applications of the
program if you follow it's instructions.  It tells you to put a blank
formatted floppy in drive A, and it then copies files onto it.  Then
you are asked to put the diskette in another computer and type
A:SHARE.  We're still pursing this path.

It may also do other damage - we're still investigating, but what
we've found so far is enough to make me want to issue an urgent
warning.

If you've already installed it, remove it.  You can do this
temporarily by making the AUTOEXEC.BAT file (in the root directory)
read/write, and non-hidden, which you can do using one of a number of
utilities.  Then delete the AUTOEXEC.BAT.  This disables the trojan
lines that the install program put in.  This APPEARS to deal with the
trojan, but since there is a lot of deep stuff going on, we would not
assume that it actually does fully deal with it.

Our recommendation at this point in time, is based on the fact that
this thing is doing some pretty deep work on the disk, and since it
contains a lot of code, it will be a long time before it is completely
understood.  So as of now, our suggestion is:

First, switch off the computer, put a known CLEAN DOS diskette in
drive A, and switch on again.  This makes sure that the trojan has no
control.  Back up all your data files using a file-by-file backup.
Format the disk, reload all your executables from known clean
diskettes, and restore the data files.  You should take two backups,
in case the first one fails to restore.

If you haven't installed it, don't and tell everyone else not to.  The
police have been brought into this case; if you wish to make a formal
complaint to the Computer crime unit, please contact Detective
Sergeant Donovan on 01-725 2434.  Also, contact him if you have any
useful information.

If you want more information about this trojan, it will be covered in
full in Virus Fax International - please call if you want to know more
about this.

Please note that the information has been got out quickly as possible,
and is therefore subject to change in the details.

ALAN SOLOMON

------------------------------

Date:    Thu, 14 Dec 89 13:31:49 +0000
From:    Martin Ward <[e-mail]>
Subject: Re AIDS disk (PC)

I feel that I should point out that the effects of this disk are
entirely in accordance with the standard warrenty used by most
commercial software developers (the ones which disclaim that the
programs are fit for any purpose at all, that XXX will disclaims all
responsibility for any damage or loss caused etc.) Either these
warrenties are ILLEGAL or the perpetrators of this disk are entirely
within their legal rights to do what they have done. Does anyone (eg a
lawyer) know which is the case?

                        Martin.

My ARPANET address is:  [e-mail]
OR: [e-mail]  UUCP:...!mcvax!ukc!easby!martin
JANET: [e-mail]    BITNET: [e-mail]

------------------------------

Date:    Thu, 14 Dec 89 10:05:36 -0500
From:    [e-mail]
Subject: What does the WDEF virus do? (Mac)

I just discovered that a scribes disk (one that is used by many different
typists at different times to compile class notes) that crashed was
infected with the WDEF virus.  The Mac SE FDHD that I am using now had
trouble reading the disk and MacTools confirmed that there were many
damaged blocks.  After using Symantec's utilities to recover the files on
the disk, including the desktop, I checked to see if the file had the WDEF
virus.  It did.
I reformatted the scribe disk with no problems and verified that it was ok
after the reformatting.  Did it crash because of WDEF?  What's the latest
on what WDEF does?
Thanks!
   --Jeff

------------------------------

Date:    Thu, 14 Dec 89 18:02:03 +0000
From:    Matthew Moore <[e-mail]>
Subject: Re: Update on AIDS Trojan (PC)

This afternoon I was one of a small team which successfully tracked
down the method of invocation of the Aids trojan, on a pc clone which
was infected, but not devastated.

Definition : <255> = the ascii character 255 , aka  hex FF

The program is called:                     rem<255>.exe
(ie 4 char filename which shows as 3)

It resides in a hidden directory called:   \<255>
(ie a 1 char filename)

It is invoked by two lines in the autoexec.bat file :-

cd \<255>                    (which if course usually looks like : cd \ )
rem<255> some statement      (which looks like : rem  some statement)

There two additional features worth noting:-

i)  there is another root level hidden directory, also using a nonprintable
    character (I dont know which), containing further hidden subdirectories
    to four levels down, and at the bottom are files which appear to contain
    data from elsewhere on the disk, and sundry other info.

ii) there is a red herring in the autoexec.bat file.
    Underneath the two statements listed above, the line 'auto.bat'
    followed by an EOF (^Z).
    The file \auto.bat contains the original autoexec.bat

Presumably, it would be stopped by removing or renaming \<255>\rem<255>.exe
and reverting to a clean auotexec.bat .

(Corrections to this presumption welcome!)

- --
[e-mail]                   | Post: Computing & Statistics Unit
JANET   :  [e-mail]        |       Institute of Neurology
INTERNET: try mjm%cu.neur.lon.ac.uk     |       Queen Square, London, WC1
Phone   : [phone]                   |       London   WC1 3BG

------------------------------

Date:    Thu, 14 Dec 89 16:20:56 -0500
From:    [e-mail]
Subject: Disinfectant 1.5 (Mac)

Disinfectant 1.5
================

December 14, 1989

Disinfectant 1.5 is a new release of our free Macintosh virus
detection and repair utility.

Shortly after the release of version 1.4, a new strain of the WDEF
virus was discovered.  Version 1.5 has been configured to recognize
the new strain.  Version 1.5 also contains code to detect and repair
other strains of WDEF which may exist but have not yet been reported.

Disinfectant 1.5 is available now via anonymous FTP from site
acns.nwu.edu [129.105.49.1].  It will also be available soon on
sumex-aim, comp.binaries.mac, ComuServe, Genie, Delphi, BIX, MacNet,
America Online, Calvacom, and other popular sources for free and
shareware software.

The following text is extracted from the new section on WDEF in
Disinfectant's online document.  It describes what we know to date
about this new virus.  The description has been expanded to include
new information that has recently become available.

The WDEF virus was first discovered in December, 1989 in Belgium
and in one of our labs at Northwestern University. Since the
initial discovery, it has also been reported at many other
locations throughout the United States, so we fear that it is
widespread. We have reason to believe that the virus has been in
existence since at least mid-October of 1989. We know of two
strains, which we call "WDEF A" and "WDEF B."

WDEF only infects the invisible "Desktop" files used by the
Finder. With a few exceptions, every Macintosh disk (hard drives
and floppies) contains one of these files. WDEF does not infect
applications, document files, or other system files. Unlike the
other viruses, it is not spread through the sharing of
applications, but rather through the sharing and distribution of
disks, usually floppy disks.

WDEF may have been introduced initially via a Trojan Horse
application, in a fashion similar to the way the MacMag virus was
first introduced via a Trojan Horse HyperCard stack. We do not yet
know if this is indeed the case, and we may never know.

WDEF spreads from disk to disk very rapidly. It is not necessary
to run a program for the virus to spread.

The WDEF A and WDEF B strains are very similar.  The only
significant difference is that WDEF B beeps every time it infects
a new Desktop file, while WDEF A does not beep.

Although the virus does not intentionally try to do any damage,
WDEF contains bugs which can cause very serious problems. We have
received reports of the following problems:

* The virus causes both the Mac IIci and the portable to crash.
* Under some circumstances the virus can cause severe performance
problems on AppleTalk networks with AppleShare servers.
* Many people have reported frequent crashes when trying to save
files in applications under MultiFinder.
* The virus causes problems with the proper display of font styles
(the outline style in particular).
* We have two reports that the virus can damage disks.
* We have a report that the virus causes Macs with 8 megabytes of
memory to crash.
* We have a report that the virus is incompatible with the
"Virtual" INIT from Connectix.

Even though AppleShare servers do not use the normal Finder
Desktop file, many servers have an unused copy of this file
anyway. If the AppleShare administrator has granted the "make
changes" privilege to the root directory on the server, then any
infected user of the server can infect the Desktop file on the
server. This is one of the situations which can lead to the severe
performance problems mentioned above. For this reason,
administrators should never grant the "make changes" privilege on
server root directories. We also recommend deleting the Desktop
file if it exists. It does not appear that the virus can spread
from an AppleShare server to other Macs on the network, however.

When using Disinfectant to repair WDEF infections, you must use
Finder instead of MultiFinder. Under MultiFinder the Desktop files
are always "busy," and Disinfectant is not able to repair them. If
you try to repair using MultiFinder, you will get an error
message.

Unfortunately, when the WDEF virus first appeared, none of the
current versions of the most popular virus prevention tools were
able to detect or prevent WDEF infections. This includes Vaccine
1.0.1, GateKeeper 1.1.1, Symantec's SAM Intercept 1.10, and HJC's
Virex INIT 1.12.

Chris Johnson, the author of Gatekeeper, has released "GateKeeper
Aid," a free system startup document (INIT) that detects and
automatically removes WDEF infections and notifies the user of the
infection. GateKeeper Aid can be used together with GateKeeper or
together with Vaccine to provide protection against WDEF.

New versions of the commercial tools should also be released soon,
and we expect that at least one other free protection tool will
also be available soon.

It is very important that all Mac users obtain and install
GateKeeper Aid or some other WDEF protection tool. You can use
Disinfectant to remove an existing infection, but if you do not
install a protection tool you may very likely become infected
again.

In addition to the two known strains of the WDEF virus,
Disinfectant will also detect and repair other strains which may
exist but have not yet been reported. If an unknown strain is
detected, Disinfectant places the following message in the report:

   ### File infected by an unknown strain of WDEF

If you see this message, and if you have not already repaired the
file, we would appreciate it if you would send a copy to the
author. The author's addresses are at the end of this document.
You may need the assistance of an expert, since the Desktop files
that are infected by the WDEF virus are normally invisible. You
should use ResEdit or some other file editing tool to make the
file visible, then make a copy to send to us, then use the same
tool to make the original file invisible again, and use
Disinfectant to repair it. Send the copy to the author, then
delete the copy.

Please do not worry if you are not comfortable with these
instructions and you do not have access to an expert. Go ahead and
repair the infected file. It is more important that you rid your
system of the virus than it is for us to get a copy of the unknown
strain.

This version of Disinfectant is being released only one week after
the discovery of the WDEF virus. We do not yet understand it as
thoroughly as we do the other older viruses. We have disassembled
it completely, and we understand the basic replication mechanism.
We know that it can cause serious problems, and we know why it
causes some of the problems. Research into the behavior and
adverse effects of this virus will continue for some time.

You should keep in touch with your local Mac user group or
bulletin board for more information about this new virus as it
becomes available. Commercial online services like CompuServe and
Genie and the Macintosh trade press publications like MacWeek are
also good sources of information.

When the WDEF virus was first discovered, the authors of most of
the popular virus-fighting programs and other experts immediately
began working together to analyze and test the virus. The
information presented here is a compilation of our joint
discoveries. The author would like to thank everybody who helped
in the investigation. Particular thanks to Chris Johnson
(GateKeeper), Jeff Shulman (VirusDetective), Paul Cozza (SAM),
Robert Woodhead (Virex), Dave Platt, Werner Uhrig, and the Apple
Virus Rx team. Thanks also to the many Mac users who sent reports
of WDEF sightings and problems caused by the virus.

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208

Bitnet: jln@nuacc
Internet: [e-mail]
CompuServe: 76666,573
AppleLink: A0173

------------------------------

Date:    Thu, 14 Dec 89 17:31:10 -0500
From:    Lynne Meeks <[e-mail]>
Subject: WDEF found at University of Vermont (Mac)

We discovered we have at least one Mac with the WDEF virus. The most
likely source is a disk brought here from Dartmouth by a student.
although there is another (unknown) potential source.  The virus was
discovered (and successfully removed) by Virus Detective 3.1 which we
were trying out. We did not have any indication we had a virus.  Guess
this one travels fast...

------------------------------

Date:    Thu, 14 Dec 89 19:08:00 -0500
From:    IA96000 <[e-mail]>
Subject: AIDS TROJAN (PC)

The AIDS trojan does bring up some interesting questions. Political
issues aside for a second, what makes anyone think that the company or
individuals behind this are in Panama?

Just because the mail goes to Panama does not mean a thing. There
are also more lax regulations (I would assume) about renting post
office boxes outside of the United States.

Has anyone considered that this might be work of the people who
introduced BRAIN to the world? Other than the address, it might
well be the same culprits.

Rather than worry about who did it, perhaps it would be a better
idea to figure out what to do about? After all the potential for
damage is quite high, and little seems to be know about what is
happening, so far.

------------------------------

Date:    14 Dec 89 23:32:14 +0000
From:    emx.utexas.edu!ut-emx![e-mail] (Chris Johnson)
Subject: Gatekeeper Aid 1.0 Released (Mac)

Gatekeeper Aid 1.0 of 13-Dec-89
by Chris Johnson (c) 1989

Gatekeeper Aid is a supplement to version 1.1.1 of the Gatekeeper
Anti-Virus System.  Gatekeeper Aid is a new component designed to
locate and remove the WDEF viruses that have recently appeared
and which are not hindered by Gatekeeper's existing security
system.  Gatekeeper Aid also checks for possible future variants
of WDEF.

Gatekeeper Aid automatically checks files as they are used for
the presence of specific viruses and, if viruses are found, it
removes them.  Like Gatekeeper, Gatekeeper Aid runs continuously
without the attention (and usually without the awareness) of the
user.

Unlike Gatekeeper, Gatekeeper Aid requires no configuration by
the user -- it's objectives are specific enough that there's
simply no need for configuration at this point.

Although Gatekeeper Aid is designed to supplement Gatekeeper,
it does not require that Gatekeeper be present in order to
operate.

Gatekeeper Aid has been posted to comp.binaries.mac, and is
immediately available for anonymous ftp from ix1.cc.texas.edu
and ix2.cc.utexas.edu.  You'll find it (and Disinfectant 1.5)
in the ~microlib/mac/virus directory.

The IP addresses of ix1 and ix2 are, respectively, 128.83.1.21
and 128.83.1.29.

Gatekeeper Aid will should be available from sumex and simtel
in the near future.

Cheers,
- ----Chris Johnson
- ----Author of Gatekeeper
- [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 18 Dec 1989    Volume 2 : Issue 262

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

AIDS Trojan Update (PC)
Re: Major Trojan Warning (PC)
Possible GateKeeper Aid bug? (Mac)
Virus Hearing on TV (CPSR, too)
AIDS Trojan Update #3 (PC)
Virus info (Atari ST)
AIDS TROJAN RESEARCH (PC)

---------------------------------------------------------------------------

Date:    Thu, 14 Dec 89 15:17:28 -0800
From:    [e-mail]
Subject: AIDS Trojan Update (PC)

A forward from John McAfee:

        Our investigation has turned up surprise: PC Cyborg
Corporation has indeed been registered in the country of Panama.  The
registration date was 04-12-89, legal deed #16653.  The resident agent
for due process is listed as Lucia Bernal.  The directors are: Kitain
Mekonen, Asrat Wakjira and Fantu Mekesse.  Since the names of the
directors are all West African, it appears that the story told by
Ketema Corporation about representing a Nigerian software firm may be
close to the truth.  The story unfolds.
        We still have no verified reports of mailings to the U.S.
Let's hope we continue to have none.  Needless to say, if anyone does
receive the AIDS diskette, do not use it.

John McAfee

------------------------------

Date:    15 Dec 89 11:04:05 +0000
From:    Chris Moss <[e-mail]>
Subject: Re: Major Trojan Warning (PC)

[e-mail] writes:
>This is an urgent forward from John McAfee:
>
>     A distribution diskette from a corporation calling itself
>PC Cyborg has been widely distributed to major corporations and
>PC user groups around the world and the diskette contains a
>highly destructive trojan.

Further information from the London "Independent" newspaper 15 Dec
bylined by Science Editor Tom Wilkie, titled 'Trojan' threatens 10,000
computers:

Fears are growing that more than one mailing list was used
todistribute the "Aids Information" computer diskette which is
damaging computers.

Police said yesterday that they had been "inundated" by thousands of
complaints about the disk, which they believe may have been
distributed to more than 10,000 addresses in Britain. There are also
unconfirmed reports tha delegates to an Aids conference in Sweden have
been sent copies of the diskette from London.

Experts estimate that the cost of the operation must run to between
8,000 and 10,000 pounds.

...

According to Dr Alan Solomon, a leading expert on computer security,
the program counts the times a user switches on the machine.

After about 90 startups, Dr Solomons said, the damage routine is
triggered. The program encrypts the names of all files held on the
hard disks and "hides" them. This means that the computer's normal
operating software is unable to find anything except one file,
"CYBORG.DOC" which contains a demand for payment.

According to Steve Robinson of the software company Insoft, the damage
routine may be triggered on some machines almost as soon as the
program is run.  ...

>In addition, the British magazine "PC Business World" has
>included a copy of the diskette with its most recent publication

 (I do not confirm the truth of this assertion, but the article continues)

PC Business World has produced an "Aidsout" program, written by virus
hunter Jim Bates, on a disk which the magazine will distribute free to
victims.  The program is also available on "Connect" the IBM PC User
Group bulletin board.

... (various other symptoms)

Experts agree the program is so big and cleverly written that it will
take months to tease out all the things it may do.  For that reason,
users should remove all trace from machines as soon as possible.

For free information send a SAE to: IBM PC User Group, PO Box 360,
Harrow HA1 4LQ; or Dr. Alan Solomon, S and S, Watermeadow, Chesham,
Bucks, HP5 1LP.

------------------------------

Date:    15 Dec 89 20:27:36 +0000
From:    [e-mail] (Dick Mead)
Subject: Possible GateKeeper Aid bug? (Mac)


After seeing the posting of a download location for GateKeeper AID,
the WDEF & clone eradicator, I grabbed it and tried it out on various
Macs here. All seemed okay until this morning when a Mac froze when
using Excel 2.2 and attempting to use the Print Setup or Print
functions.  Removal of GateKeeper AID resolved the hang. This was on
both a Mac II, and an SE/30, running Multifinder. I tried renaming the
init to zGateKeeper AID to make it the last init, and the Mac
complained that it could not load the Finder. Removal of the init
again resolved that. I thought potential users, and the author should
be warned.  By the way, other than the freeze/crash above, it worked
as expected, and WDEF does seem to be everywhere. Sorta like
'chicken-man'...

------------------------------

Date:    Fri, 15 Dec 89 12:57:44 -0800
From:    cdp![e-mail]
Subject: Virus Hearing on TV (CPSR, too)

The November House Judiciary Committee hearing on computer virus legislation
will be shown on C-Span on December 23 (8:45 am) and December 24 (1:30 am).
This was an interesting and timely event with representatives from NIST,
ADAPSO, CBEMA, CPSR (!) and members of Congress discussing technical and legal
responses to the issues raised by computer viruses.

The prepared CPSR statement on computer virus legislation is available from the
CPSR Washington office.  Please send me a note if you would like a copy.

Marc Rotenberg.



------------------------------

Date:    Sat, 16 Dec 89 10:24:58 -0800
From:    [e-mail]
Subject: AIDS Trojan Update #3 (PC)

This is a forward from the HomeBase BBS:

AIDS TROJAN UPDATE   Santa Clara, California.   December 16, 1989

     Our reports of the AIDS trojan over the past three days have
been sporadic, incomplete and conflicting.  Much of the
confusion, as we are now beginning to understand, stems from the
fact that the architecture of this trojan is orders of magnitude
more complex and interwoven than any PC based virus or trojan
yet encountered.  No one has yet successfully disassembled this
trojan, nor will they for some time to come.  The two EXE files
comprising the trojan diskette represent over 320K of compiled
Microsoft Basic code, much of it encrypted.  The trojan evolves
over time and uses multiple steps to create hidden and
interrelated directories, DOS shell routines and self modifying
utilities.   Numerous techniques have been employed by the
architects to avoid detection, analysis or tampering.  The
dissection is like peeling an onion with a paper clip.
     At this point, however, having used live trials of five
different samples of the mailing diskette, we have bounded the
beast and have at least uncovered the main elements of the
underlying structure.  We've learned enough to know that a
system can be recovered after the bomb goes off (albeit using
brute force), and we have a program that can disarm the trojan if
caught before activation.  A brief outline follows:

Activation:
     All of our samples consistently and repeatedly activated
after exactly 90 reboots of the system, from the time the install
program was executed.  This agrees with Dr. Solomon's
observations of two additional samples.  An anomaly that cannot
be explained is that more than a dozen verified cases reported
activation after the first reboot.  Did the designers include a
few copies that would activate prematurely as a warning?  Is
there a bug somewhere in the install or count routine?  This is a
question that needs answering.

Installation:
     Installation requires an average of 90 seconds.  A point
that has not been mentioned before, is that a reference number is
prominently displayed during installation.  The instructions are
to include this reference number when registering the program.
After activation, the same reference number is again displayed,
with clear instructions to include the number on all
correspondence.  Could this be used in some way during the
encryption/decryption process?  An example 12 digit reference
number is: A9738-1655603-.
     The Trojan creates several hidden subdirectories -- made up
of space and ASCII 255's  -- in the root of drive C.  The install
program is copied into one of these and named REM.EXE.  The
user's original AUTOEXEC.BAT file is copied to a file called
AUTO.BAT.  The first line of this file reads -- "REM Use this
file in place of AUTOEXEC.BAT for convenience".  The installation
also creates a hidden AUTOEXEC.BAT file that contains the
commands:

          C:
          CD \
          REM  Use this file in place of AUTOEXEC.BAT
          AUTO

     The CD \ actually contains ASCII characters 255, which
causes the directory to change to one of the hidden directories
containing the REM.EXE file.  The REM file is then executed and
decrements a counter at each reboot.

Activation:
     After 90 reboots, a message appears in the center of the
screen:

          The software lease for this computer has expired.  If
          you wish to use this computer, you must renew the
          software lease.  For further information turn on the
          printer and press return.

     When the return key is pressed, the following document is
printed on the printer:

          "If you are reading this message, then your software
lease from PC Cyborg Corporation has expired. Renew the software
lease before using this computer again. Warning: do not
attempt to use this computer until you have renewed your
software lease. Use the information below for renewal.

 Dear Customer:

 It is time to pay for your software lease from PC Cyborg
Corporation.  Complete the INVOICE and attach payment for the
lease option of your choice. If you don't use the printed
INVOICE, then be sure to refer to the important reference numbers
below in all correspondence. In return you will receive:
 - a renewal software package with easy-to-follow, complete
instructions;  - an automatic, self-installing diskette that
anyone can apply in minutes.

 Important reference numbers: A9738-1655603-

 The price of 365 user applications is US$189. The price of a
lease for the lifetime of your hard disk is US$378.  You must
enclose a bankers draft, cashier's check or international money
order payable to PC CYBORG CORPORATION for the full amount of
$189 or $378 with your order. Include your name, company,
address, city, state, country, zip or postal code. Mail your
order to PC Cyborg Corporation, P.O. Box 87-17-44, Panama 7,
Panama.

After this document is printed, the following warning appears:

          Please wait thirty minutes during this operation.  Do
          not turn off the computer since this will damage your
          system.  You will be given instruction later.  A
          flashing hard disk access light means WAIT!!!!!

This message remains displayed for up to an hour and a half on
some machines while heavy disk activity continues.

The Results:
     At the end of the disk activity, a new file appears at the
root of drive C called CYBORG.DOC.  The contents of the file are
the above instructions for registering the program.  There appear
to be 0 bytes remaining on the disk if a directory listing is
attempted.  A shell routine has also been installed in the
system.  It is a program called CYBORG.EXE, with hidden read-only
attributes.  This shell routine displays the following message
after every DOS function call:

          WARNING:  You risk destroying all of the files on drive
          C.  The lease for a key software package has expired.
          Renew the lease before you attempt any further file
          manipulations  or other use of this computer.  Do not
          ignore this message.

     If an attempt is made to run a program or perform any file
manipulation, an illegal command or filename message appears.  If
the system is powered down and booted from a floppy, the only
file that appears on the disk is the CYBORG.DOC file.  There are
0 bytes free.  In reality all files that existed before have been
encrypted and given hidden attributes.  The following directory
listing is a sample from one of the activated 20 megabyte disks
where the file attributes have been cleared:

 Volume in drive C has no label
 Directory of  C:\

#UCU#R    AK    10071  13-07-85   1:43p
#UC@R&    AK    27760   3-07-85   1:43p
COMMAND  COM    23717  13-07-85   1:43p
#1!8_68@  AU      587   3-19-89   9:11a
6#1N      AK       32   2-27-89  12:33p
KF{0U     AK      853  13-12-89   4:07p
}G6R      AG       98   1-04-80  12:01a
AUTOEXEC BAT      108   1-04-80  12:01a
AUTOEXEC BAK       17   1-04-80  12:01a
}#@&      AU   172562   8-07-89  10:40a
&_}1      AU    46912  12-07-89  11:58a
!}        AU     7294   3-01-87   4:00p
1G        AU   102383   3-01-87   4:00p
H8C       AU   146188   1-04-80  12:11a
CYBORG   DOC     1326   1-04-80  12:05a
CYBORG   EXE      642   1-04-80  12:05a
AUTO     BAT      117   1-04-80  12:06a
       17 File(s)         0 bytes free

     In addition to the above, a number of hidden
subdirectories exist containing what appears to be an indexed
sequential data base with fields initialised to 20H.  This data
base occupies the entire free space of the disk.  The AUTOEXEC
file calls the CYBORG.EXE program, which is the above mentioned
DOS shell routine.  After the system is powered down, the hard
disk will no longer boot.  However, if the file AUTOEXEC is
executed at least once, the a <ctrl><alt><del> sequence will
appear to perform a re-boot and the system will on the surface
appear to be normal as described above, with the exception of the
warning message after a DIR or other DOS command.  If the file
CYBORG.EXE is examined using Norton or other similar utility the
following text is found at offset 560:

     <false end-file-marker>  <The Norton Utilities cannot read
     this file because the FAT has been locked> BORG  EXE

     No code can be found in the file.  However, a sector search
of the disk finds the CYBORG.EXE code at various offsets.  Inside
the code is the text listing of the hard disk directory structure
prior to the encryption.  The text corresponding to the above
encrypted root directory is:

 Volume in drive C has no label
 Directory of  C:\

IBMBIO   COM    10071  13-07-85   1:43p
IBMDOS   COM    27760   3-07-85   1:43p
COMMAND  COM    23717  13-07-85   1:43p
INFECTED EXE      587   3-19-89   9:11a
TINY     COM       32   2-27-89  12:33p
W13_B    COM      853  13-12-89   4:07p
AUTO     BAT       98   1-04-80  12:01a
AUTOEXEC BAT      108   1-04-80  12:01a
AUTOEXEC BAK       17   1-04-80  12:01a
AIDS     EXE   172562   8-07-89  10:40a
SCAN     EXE    46912  12-07-89  11:58a
FA       EXE     7294   3-01-87   4:00p
NU       EXE   102383   3-01-87   4:00p
REM      EXE   146188   1-04-80  12:11a
       14 File(s)  15872000 bytes free

     A comparison of the encrypted and unencrypted entries
indicates that some form of linear character mapping was used
(i.e.   # = I, } = A, 8 = E, @ = D, etc.)

     All of the data in the system appears to be intact and not
encrypted.  The partition table and boot sector have not been
modified in any way.  The system can be recovered by removing the
hidden directories and their contents, and by replacing the
encrypted entries in the FAT with the entries found in the
CYBORG.EXE file.  Currently this has to done by hand.  We are
working on a program to perform this task.
     If you catch this trojan before it activates, then Jim
Bate's AIDSOUT.COM program available on HomeBase will extract the
trojan and return the system to its original condition.


Remaining questions:
     Dr. Solomon reports that his sample created one additional
file called SHARE.EXE that had instructions to install the SHARE
program on a second computer and then return it to the affected
system.  The instructions stated that running the SHARE program
again on the affected system would provide 30 free re-boots of
the system with all data restored.  Our samples did not create
this SHARE program and no instructions pertaining to it were
given.  Whether this was a difference in diskettes or perhaps
attributable to our non-standard test machines we do not know.

John McAfee

------------------------------

Date:    Sat, 16 Dec 89 05:36:21 -0900
From:    "Big MAC..." <[e-mail]>
Subject: Virus info (Atari ST)

I have a question for all. What is known about Viruses for the ATARI
ST?  I have seen alot of viruses discussed about the PC and MAC , and
a friend of mine has an ST that is behaving wierdly after warm boot.
Any Information? Thankx...

                        [e-mail]

------------------------------

Date:    Sun, 17 Dec 89 17:54:00 -0500
From:    IA96000 <[e-mail]>
Subject: AIDS TROJAN RESEARCH (PC)

I have been asked to pass this message along to VIRUS-L and VALERT-L
by the fine people at SWE who have been hard at work researching the
AIDS problem. I pass this message along unmodified exactly as it was
received from SWE.

             AIDS "TROJAN" DISK UPDATE - DECEMBER 17, 1989

First, let us say for the record that everything reported so far by
Mr. McAfee is correct. Our tests bear out the results he has obtained.

Having followed the messages and updates so far, and after conducting
extensive tests, SWE has no doubt that there is more than one version
of the "trojan" disk in circulation. In certain aspects, the two AIDS
"trojan" disks we are testing act differently. One has a counter in it
and one activates on the first re-boot!

SWE has been working 24 hours a day since we received a copies of the
AIDS disks. Let me clarify that statement. We did not receive these in
the mail directly from the "trojan" authors. We received our copies
from two of our clients.

The suspicion that some form of encryption is being used is accurate.
The versions of the disks we tested checks the following criteria:

1) The version of DOS in use. Both major and minor numbers are used.
   The major number would be 3 and the minor number would .30 in
   DOS version 3.30.

2) The file length, date and time stamp of certain files are checked.

3) The amount of total disk space and free disk space are checked.

These three items are then combined and processed into the "initial"
encryption key.

A form of public key encryption is then used to perform the actual
encryption. This was determined by the brute force decryption method.
SWE has several 80486's and access to a VAX and they were put to work
decrypting the files. It was made easier by the fact that the original
contents of the test disk were known. One nasty little trick the AIDS
"trojan" uses is that after each file is encrypted the encryption key
is modified slightly.

Fortunately, the authors did not use a long encryption key. Files
encrypted using the public key protocol become harder to decipher as
the length of the encryption key increases. Government studies
indicate that a file encrypted using this protocol, with a 200 digit
key could take as long as ten (10) years to decrypt, if you devoted a
CRAY exclusively to the problem!

SWE first suspected and tested for the public key encryption method
for several reasons. The major reason was the lack of access people
outside of the United States would have to the DES encryption formula.

For those not aware, the U.S. Government guards the DES formula, and
software which makes use of this formula may not be exported out of
the United States. Should it turn out that the DES formula was also
used, the authors of the AIDS "trojan", could possibly be prosecuted
under United States statutes pertaining to national security.

The second reason deals with the DES encryption method. Students of
cryptology are well aware that the DES formula has been considered
vulnerable for some time now. It is also a well know fact that DES
specific processors have been produced, which make "cracking" a DES
encrypted file much easier than the public key method. The DES method
also limits to a greater degree the length of the encryption key.

Combining these two reasons along with the extraordinary expense the
authors of the AIDS "trojan" went to, we guessed that they would also
use a "first class" encryption method.

It also makes sense from another point of view. Since the "trojan"
authors have gone to great care and expense, it seems prudent they
would not want to use an encryption method which could easily be
copied and distributed as a "master" cure all. Public key encryption
is perfect in this regard. Many different versions of DOS are now
in use, and depending upon the version of DOS in use and other factors
the "trojan" checks for, the decryption methods which must be used
will vary for different "trashed" disks.

This is not to say that other copies of the AIDS "trojan" will use
this same encryption method, or create the encryption keys in the same
manner. That is yet to be determined!

Once we were able to decipher one file, it was a relatively simple
matter to decipher the rest. We have been able to completely restore a
disk trashed by the version of AIDS "trojan".

SWE went about this research in a different manner than everyone else.
We have not reverse engineered the "trojans" to any great extent, nor
do we plan to do so. This is best left to Mr. McAfee and the other
experts.

It is our considered opinion that Quick Basic along with several
machine language modules were used to develop these "trojans". Reverse
engineering a Quick Basic program along with the libraries included at
link time produces huge amounts of code.

As far as releasing the "fixes", not enough is yet known by SWE to be
able to provide a substantial program. We need more information about
how many versions of the AIDS "trojan" are in circulation, as well as
samples of these for study. SWE has no intention of publicly releasing
a "fix" at this time or in the future.

It is our opinion that the best course SWE can take is to share our
knowledge with others who have the knowledge and experience to take
what we learned and investigate further.

To that end, SWE is willing to forget past differences with a specific
company and share our files as well as the "fixes" and our knowledge
on cryptology with them, for the good of the computing community. If
they are interested, leave a public message on your BBS in the virus
SIG. Some type of agreement can be reached if you are interested in
doing so!

The opinions and statements expressed herein are those of SWE. These
are based on research done on two copies of the AIDS "trojan" disk we
have tested. Findings produced by other people working on this problem
may agree, vary, or contradict our findings. So be it! SWE is not
competing with anyone else working on this problem. We present this
information solely to acquaint the computing community on the details
we have discovered so far.

The information contained in the message above was supplied by the
people at SWE, who have postponed their vacation closing to conduct
research into the AIDS problem.

It is my opinion that everyone should band together on this one! The
AIDS disk seems to be very complicated and it will probably take the
combined knowledge of everyone working on this disaster to come up
with a solution.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 19 Dec 1989    Volume 2 : Issue 263

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Use of Digital Signatures
SCAN Update for AIDS Trojan (PC)
Source for virus detction programs (PC)
WDef and Gatekeeper Aid.
New/Old(?) Possible Virus (PC)
AIDS TROJAN RESEARCH
Re: AIDS Trojan (PC)
Aids cures (PC)

---------------------------------------------------------------------------

Date:    Mon, 18 Dec 89 14:20:55 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Use of Digital Signatures

  When I submitted my contribution on Signature Programs (Issue 256) I
wouldn't have been surprised to be criticized for something I wrote,
but I hardly expected to be criticized for something I *didn't* write!
According to William Murray (#257),
>                             The insistence of Mr. Radai et. al. that,
>since it is possible to detect and bypass any control, that all is
>futile does not stand up.  ....
>It is time to stop condemning the useful out of hand.  Those who insist
>upon doing so are contributing to the problem rather than the solution.

  Just where, Mr. Murray, did you find in anything which I wrote, that
I "insist" that "all is futile" or that I "condemn the useful"???  I
never said anything remotely resembling these things.  The point I was
making was: Security of the algorithm is not enough; what's important
is the security of the implementing program.  Where's the futility in
that?
  Well, maybe Mr. Murray thinks that these conclusions are somehow
implied by the position that it's possible to detect and bypass any
control.  (Actually, I never said even *that*, but for sake of argu-
ment, let's suppose that I did.)  Just how is that supposed to imply
that all is futile??  My actual opinion is quite the opposite: it's
that even if we can't create a perfect checksum or other anti-viral
program, we should make an effort to think of all possible holes in
the system, and the more we block, the better.  There is absolutely no
implication of futility or condemnation of the useful either here or
in my original posting.  In the future, Mr. Murray, please try to read
more carefully before attributing positions to others.

  There were also some peculiar claims in the paragraph following Mr.
Murray's opening line "I suspect that Y. Radai misses the point of Bob
Bosen's posting."  However, I'll leave it to Bob himself to decide
which of us missed the point of his posting, Mr. Murray or me ....

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

  P.S.  I have not been receiving Virus-L regularly for the last cou-
ple of months.  If there have been more recent (and hopefully more re-
levant!) replies to my posting which call for an answer from me,
please be patient.

------------------------------

Date:    Sun, 17 Dec 89 13:53:12 -0800
From:    [e-mail]
Subject: SCAN Update for AIDS Trojan (PC)

Forwarded for John McAfee:

        Even though the AIDS Trojan is not a true virus, the
widespread mailings of the diskette have created a high probability
that we will see continuing problems from this logic bomb.
Accordingly, I have updated SCAN (V52) to detect the installed hidden
logic bomb, and SCANRES (V52) will prevent the diskette's INSTALL
program from installing the time bomb to begin with.

John McAfee

------------------------------

Date:    18 Dec 89 15:15:41 +0000
From:    attcan![e-mail] (Richard Meesters)
Subject: Source for virus detction programs (PC)


Hi all,

I'm looking for a source for public-domain PC virus protection/detection
programs, preferrably in the Toronto area.

If anyone has a number I can call, please respond via e-mail

Regards,
Richard Meesters


------------------------------

Date:    Mon, 18 Dec 89 12:16:09 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: WDef and Gatekeeper Aid.

I booted some Macs with Gatekeeper Aid installed this AM.  I was
immediately presented with a rather sharp looking dialog announcing
that the "Implied Loader ABDS" virus(?) was found and removed.

Is this the Wdef virus?  If so, why not call it such AND what is an
"Implied Loader ABDS".  Of course, if this is Wdef you can add the
University of South Carolina to the list of where the virus has
spread.  If not I apologize to Chris Johnson and all subscriber's for
my ignorance (it has been peaking lately!).

Greg

Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Mon, 18 Dec 89 13:02:41 -0500
From:    Arthur Gutowski <[e-mail]>
Subject: New/Old(?) Possible Virus (PC)

Someone here at Wayne State just sent me a note about some strange
symptoms he's been having.  Can anyone out there verify if this is
indeed a virus, and if so which one?  Here's the info I have
(emphasis mine):

"Here's what I know. I *believe* that a disgruntled staff member *may*
 have put the virus into my computer directly since the same problem
 occurred six months ago to another administrator in the library. He
 had a student computer expert solve the problem, but this student is
 no longer with us.

"I have an IBM XT with 640 and a 20meg hard drive. I've had SCANRES
 (Ed.v39) on the system since October 11. The infection got in since
 then. SCANRES says that the system is clean. I examined the AUTOEXEC
 and CONFIG.SYS files. They look clean to me. Problems so far include:
 WordPerfect 4.2: The cursor keys add extra random characters such as a
 'z' or 'k'. I also got the message 'ARSOLE' and the system then locked
 up from another cursor key sequence.  DESKTOP in PCTOOLS. The
 calculator locked up. I had to do a cold reboot.

"I replaced my base files with the SYS command on Friday and haven't
 noticed any problems yet, but the problems that I described above are
 extremely intermittent."

 Please reply to me, and I'll post a follow-up later.

 Thanks,
   Art

 Arthur J. Gutowski                                                  /=====\
 Antiviral Group / Tech Support / WSU University Computing Center   :  o o  :
 5925 Woodward; Detroit MI  48202; PH#: [phone]              :       :
 Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]       : ----- :
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-   \=====/
                                                                   Have a day.

------------------------------

Date:    Sun, 17 Dec 89 17:54:00 -0500
From:    IA96000 <[e-mail]>
Subject: AIDS TROJAN RESEARCH

I have been asked to pass this message along to VIRUS-L and VALERT-L
by the fine people at SWE who have been hard at work researching the
AIDS problem. I pass this message along unmodified exactly as it was
received from SWE.

             AIDS "TROJAN" DISK UPDATE - DECEMBER 17, 1989

First, let us say for the record that everything reported so far by
Mr. McAfee is correct. Our tests bear out the results he has obtained.

Having followed the messages and updates so far, and after conducting
extensive tests, SWE has no doubt that there is more than one version
of the "trojan" disk in circulation. In certain aspects, the two AIDS
"trojan" disks we are testing act differently. One has a counter in it
and one activates on the first re-boot!

SWE has been working 24 hours a day since we received a copies of the
AIDS disks. Let me clarify that statement. We did not receive these in
the mail directly from the "trojan" authors. We received our copies
from two of our clients.

The suspicion that some form of encryption is being used is accurate.
The versions of the disks we tested checks the following criteria:

1) The version of DOS in use. Both major and minor numbers are used.
   The major number would be 3 and the minor number would .30 in
   DOS version 3.30.

2) The file length, date and time stamp of certain files are checked.

3) The amount of total disk space and free disk space are checked.

These three items are then combined and processed into the "initial"
encryption key.

A form of public key encryption is then used to perform the actual
encryption. This was determined by the brute force decryption method.
SWE has several 80486's and access to a VAX and they were put to work
decrypting the files. It was made easier by the fact that the original
contents of the test disk were known. One nasty little trick the AIDS
"trojan" uses is that after each file is encrypted the encryption key
is modified slightly.

Fortunately, the authors did not use a long encryption key. Files
encrypted using the public key protocol become harder to decipher as
the length of the encryption key increases. Government studies
indicate that a file encrypted using this protocol, with a 200 digit
key could take as long as ten (10) years to decrypt, if you devoted a
CRAY exclusively to the problem!

SWE first suspected and tested for the public key encryption method
for several reasons. The major reason was the lack of access people
outside of the United States would have to the DES encryption formula.

For those not aware, the U.S. Government guards the DES formula, and
software which makes use of this formula may not be exported out of
the United States. Should it turn out that the DES formula was also
used, the authors of the AIDS "trojan", could possibly be prosecuted
under United States statutes pertaining to national security.

The second reason deals with the DES encryption method. Students of
cryptology are well aware that the DES formula has been considered
vulnerable for some time now. It is also a well know fact that DES
specific processors have been produced, which make "cracking" a DES
encrypted file much easier than the public key method. The DES method
also limits to a greater degree the length of the encryption key.

Combining these two reasons along with the extraordinary expense the
authors of the AIDS "trojan" went to, we guessed that they would also
use a "first class" encryption method.

It also makes sense from another point of view. Since the "trojan"
authors have gone to great care and expense, it seems prudent they
would not want to use an encryption method which could easily be
copied and distributed as a "master" cure all. Public key encryption
is perfect in this regard. Many different versions of DOS are now
in use, and depending upon the version of DOS in use and other factors
the "trojan" checks for, the decryption methods which must be used
will vary for different "trashed" disks.

This is not to say that other copies of the AIDS "trojan" will use
this same encryption method, or create the encryption keys in the same
manner. That is yet to be determined!

Once we were able to decipher one file, it was a relatively simple
matter to decipher the rest. We have been able to completely restore a
disk trashed by the version of AIDS "trojan".

SWE went about this research in a different manner than everyone else.
We have not reverse engineered the "trojans" to any great extent, nor
do we plan to do so. This is best left to Mr. McAfee and the other
experts.

It is our considered opinion that Quick Basic along with several
machine language modules were used to develop these "trojans". Reverse
engineering a Quick Basic program along with the libraries included at
link time produces huge amounts of code.

As far as releasing the "fixes", not enough is yet known by SWE to be
able to provide a substantial program. We need more information about
how many versions of the AIDS "trojan" are in circulation, as well as
samples of these for study. SWE has no intention of publicly releasing
a "fix" at this time or in the future.

It is our opinion that the best course SWE can take is to share our
knowledge with others who have the knowledge and experience to take
what we learned and investigate further.

To that end, SWE is willing to forget past differences with a specific
company and share our files as well as the "fixes" and our knowledge
on cryptology with them, for the good of the computing community. If
they are interested, leave a public message on your BBS in the virus
SIG. Some type of agreement can be reached if you are interested in
doing so!

The opinions and statements expressed herein are those of SWE. These
are based on research done on two copies of the AIDS "trojan" disk we
have tested. Findings produced by other people working on this problem
may agree, vary, or contradict our findings. So be it! SWE is not
competing with anyone else working on this problem. We present this
information solely to acquaint the computing community on the details
we have discovered so far.

The information contained in the message above was supplied by the
people at SWE, who have postponed their vacation closing to conduct
research into the AIDS problem.

It is my opinion that everyone should band together on this one! The
AIDS disk seems to be very complicated and it will probably take the
combined knowledge of everyone working on this disaster to come up
with a solution.

------------------------------

Date:    18 Dec 89 19:07:43 +0000
From:    Ralph Mitchell <[e-mail]>
Subject: Re: AIDS Trojan (PC)

[e-mail] (David Gursky) writes:
>The AIDS Trojan Horse discussed by Alan Jay and John McAfee raises some
>interesting questions about accountability.
>[...]
>In the broader case, could the perpetrators be extradicted to one of
>the European countries that have better relations with Panama, and be
>held liable for damages even though the license says not to use the
>application without first paying for it.

There is no actual address on the documentation that comes with the disk.
The only way to find out where to send the money is by running the install
program, thought it doesn't even say that in the notes...  Of course, by
that time, it is firmly ensconced on your hard disk...

Ralph Mitchell
- --
JANET: [e-mail]  ARPA:  [e-mail]
UUCP:  ...ukc!cc.brunel!ralph PHONE: [phone] x2561
"There's so many different worlds, so many different Suns" - Dire Straits
"Never underestimate the power of human stupidity" - Salvor Hardin, Foundation

------------------------------

Date:    Sun, 17 Dec 89 21:14:50 -0500
From:    Christoph Fischer <[e-mail]>
Subject: Aids cures (PC)

A I D S  -  D I S C E T T E
===========================
Dr. Solomon and I just had a phone conversation on possible cures for
the affects of the AIDS disc.
In STAGE ONE
    (the disc has been installed but the filenames are not encrypted)
Several hidden directories, a file REM.EXE, and an altered AUTOEXEC.BAT
have been installed. Some sources suggest removing these directories,
the added files, and restoring the original AUTOEXEC.BAT will cure all
effects of STAGE ONE.
Because of the uncertainty what else the program does, people who want
maximum security are advised to copy the files to diskettes after the
above procedure. Low-level format the discs and restore all programs
and data.
Dr. Solomon and I are not sure that all discs behave the same way.
Our samples don't touch harddiscs higher than C: (D:, E:, ...) but there
are reports of discs that do! (maybe just rumors?)
STAGE TWO is entered after 90 executions of the AUTOEXEC.BAT with our
samples but there are victims that claim that their version of the
software skips STAGE ONE.

In STAGE TWO the program encrypts the filenames and alters other things.
A mockup is started after reboot from the harddisc that gives you a
correct directory listing plus an added comment that the lease of the
CYBORG software has expired.
In this stage the disc contense appears to be useless.
Dr. Solomon was the first to discover a principle behind the encryption
and is working on a program to recover the original filenames.
We both think that this mechanism should only be used to backup all
data of an infected disc. A LOW-LEVEL format of the harddisc and
reinstallation of programs and data are the safest means to remove
all affects.

Sincerely Chris Fischer (University of Karlsruhe, West-Germany)
and Dr. Alan Solomon (S&S Enterprises, Chesham, Bucks, Great-Britain)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 19 Dec 1989    Volume 2 : Issue 264

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: AIDS disk (PC)
Motivation behind the AIDS trojan
WDEF protection strategy for servers (Mac)
WDEF virus.... (Mac)
AIDS TROJAN STAGE 2 UPDATE (PC)
Re: AIDS Trojan Update (PC)
AIDS Trojan Update #4 (PC)
Legal Ramifications of PC-Cyborg License
The missing viruses (PC)

---------------------------------------------------------------------------

Date:    18 Dec 89 21:49:52 +0000
From:    attcan![e-mail] (Richard Meesters)
Subject: Re: AIDS disk (PC)

[e-mail] (Martin Ward) writes:
> I feel that I should point out that the effects of this disk are
> entirely in accordance with the standard warrenty used by most
> commercial software developers (the ones which disclaim that the
> programs are fit for any purpose at all, that XXX will disclaims all
> responsibility for any damage or loss caused etc.) Either these
> warrenties are ILLEGAL or the perpetrators of this disk are entirely
> within their legal rights to do what they have done. Does anyone (eg a
> lawyer) know which is the case?

I'm afraid I can't agree with you, Martin.  Warranty implies that the
product was purchased and you are following the terms of the purchase
agreement.  The trojan runs for a time and then demands that you pay
for the product (Which, as it has been presented appears to be a
demo.)  If you don't pay the price, the trojan, in effect, kidnaps
your data and holds it for ransom.

Illegal, or at least extremely Immoral (presumably the former).

Regards,
Richard Meesters

------------------------------

Date:    18 Dec 89 22:47:23 +0000
From:    Steven Den Beste <[e-mail]>
Subject: Motivation behind the AIDS trojan

Like everyone who's heard of this thing, we here have been asking
"What are they trying to accomplish that makes them willing to spend
this much money?"

I've come up with a model for their motivation which I think explains
everything. I'd be very interested in any reactions to it:

1. They deliberately distributed two versions of the program. One
version fires immediately, while the other stays silent for 90
reboots. I'll call these "scrambled" and "infected" systems
respectively.

2. It is my guess that there are very few copies of the
fire-immediately version. It is my guess that this version was
deliberately mailed later than the others.

3. The purpose of the fire-immediately version is to make an example
of a few users. It is my guess that the authors thought they had
hidden things sufficiently well that a person who knew his system was
infected still could not find and remove the infection. This then
explains why the scrambled systems indentify clearly which program
caused the scrambling.

4. Therefore: A lot of people receive the disks "for free" and install
immediately. Infection becomes rampant.

5. A few people get their systems scrambled immediately. Word gets out
that the program is dangerous - but not immediately in most cases.

6. People with infected systems are given 90 reboots (presumably at
least a couple of months under normal usage) to send in their money
and get a dis-infector disk back.

7. Each system derives part of its encryption key from local
information. Thus the dis-infector disk can only be used on the system
for which it was returned. An organization with 10 infected systems
has to pay 10 times, and receive 10 disks.

8. The money must be sent through a dummy corporation in Panama, with
its notoriously unstrict banking laws. Payment is in US dollars
because that's what Panamanian banks deal in.

9. For a person whose system is infected but not yet scrambled, an
obvious tactic is to do a file-by-file backup onto disks or tape (as
opposed to a block-level backup), followed by a disk reformat and
rebuild, and restoration of the files. To thwart that end, I predict
that the trojan has inserted itself into one or more executable files
which would be expected to be retrieved in the backup. This may not
include the full encryption algorithm - a simple "destroy all data and
make the disk image unusable" would do. If several people get nailed
in this way, word spreads and most people won't try to escape this way
anymore. [If one is careful about what is restored and what gets
recovered from original release disks, this approach should be pretty
safe. But the kind of people who would routinely install a program
like this in the face of a "shrink-wrap" license are likely to have
other software they use for which original release disks are not
readily available. It would be my guess that such programs would be
particularly inviting targets. Likewise, the process of a file-by-file
backup and restore on an almost full 100 MB. disk is not a pleasant
prospect. It might actually cost more in floppy disks and time than
the decryptor costs.]

10. The reason the disk was not distributed in the US and that the
"license" doesn't allow it to be used here is that the behavior of
this program is in direct violation of the federal "virus" law. It
would be very interesting to know if there are any directly applicable
statute in Great Britain preventing this kind of activity. If not,
then the authors of this would be outside of the purvue of criminal
law, and protected against civil suit by their "license". They might
actually get away with it.

11. The motivation behind all this, then, is extortion. The cover
story of an AIDS database may or may not be a sick attempt at an
analogy. It may instead be a deliberate choice of a subject likely to
intrigue many people into installing the program on their systems.
(No-one has made any comment about what, if any, cover program is on
the distribution disk. Does it really contain an AIDS database?)

12. Lastly, it is my guess that the authors have badly underestimated
both the quantity and quality of the effort which has been and will be
applied to defending against this trojan (see point 3 above). This
story is not yet completely written, though - it may be that only the
first layer of defenses have been opened to our vision, and that this
thing runs much deeper (see point 9 above).

13. How do we find them?
        a. Follow the bank accounts from which the mailing lists were bought
           and from which the rent money in London was paid. (Probably tough.)
        b. Follow the bank accounts in Panama. (Forget it!)
        c. Send in your money and try to figure out where the decryptor
           disk was sent. (IF it gets sent. There is no guarantee that
           they'll follow through on the bargain.)
        d. Try to trace where they bought their computers originally
           to do the development. (Sure thing.)
        e. Just where DO we (editorial "we") start looking, and what do we
           do with them when they're found? Is there actually any way to
           bring these guys to justice under British, Swedish or West German
           law? Could they be extradited from Nigeria or somewhere like that?


Steven C. Den Beste        ||  [e-mail] (ARPA/CSNET)
BBN Communications Corp.   ||  {apple, usc, husc6, csd4.milw.wisc.edu,
150 Cambridge Park Dr.     ||   gatech, oliveb, mit-eddie,
Cambridge, MA 02140        ||   ulowell}!bbn.com!denbeste (USENET)

------------------------------

Date:    Mon, 18 Dec 89 19:19:00 -0500
From:    When I grow up I wanna be a Redneck <[e-mail]>
Subject: WDEF protection strategy for servers (Mac)

    Just an idea that may make most of our lives a bit easier.  On our
servers at SMU students often save their papers on the system disks.
Well as anybody knows this is not cool when they fill up.  Soo I throw
them away.  Not nice but I thought it got the job done until I noticed
that the desktop remembers the icons (and other stuff) that these
files contained.  Sooo I did some thinking and locked the desktops.
The result is that when papers are saved their icon's are not so
throwing them away still restores the disk to it's original free
space.  Hmmmmm (I said to my self) Wouldn't this work well in
preventing those disks from getting WDEF?  If the message from the
last Virus-l was true then this should halt the spread of our new
little virus.  But only use it if you do not expect the contents of
your disk to change - as in adding or removing files.  I hope this
works.
                                   - Alex Zavatone Mac Software
                                     Southeastern Mass U

------------------------------

Date:    19 Dec 89 01:04:18 +0000
From:    [e-mail] (Greg Ford)
Subject: WDEF virus.... (Mac)

Sure enough, my Mac II had WDEF on it.  It's first attack (on four
partitions) was December 9.  Funny thing was, immediately prior to my
discovery of this virus, my Mac II had been experiencing these same
symptoms of slow-closing windows.  In fact, it was common for the
mouse-depression lines in the go-away box of the window to take up to
5 seconds to appear and for the window to close.  This follows what
has been said about the virus earlier.  The other problem I had (which
has now gone away since erradication 5 days ago) was that when opening
a large file from the HD (Rodime, 140 Meg, Internal), it would often
crash during the read, and MacBugs would say it was damaged.  This
scared me because I haven't done a backup since September (I know, I
know no flames please), and this crash was coupled with the sound that
the HD makes when it starts up (you Rodime people know what I mean -
that click, and spinning sound).  Anyway, the problem has gone away,
and those same files open fine now that WDEF is gone.  Anyone else had
this problem?

As a side note, every single Mac on campus is infected near as I can
tell.  One lab with ~80 macs was infected in all 10 macs I randomly
sampled.  I gave the lab-room operator a copy of Disinfectant 1.5, but
he (get this) was unsure what to do with it.  I hope they've cleaned
it up.  If this thing (WDEF) passes from disk to disk just by
inserting an infected disk into a mac, can you imagine the headache
created by users who have they're own disks?  The whole lab can become
reinfected in one day.  What a mess.

*******************************************************************************
* Greg Ford                             GEnie:    G.FORD3                     *
* University of Southern California     Internet: [e-mail] *
*******************************************************************************

------------------------------

Date:    Mon, 18 Dec 89 20:46:00 -0500
From:    IA96000 <[e-mail]>
Subject: AIDS TROJAN STAGE 2 UPDATE (PC)

Forgot to mention this in yesterday's update. Sorry about that!

PKSCRYPT.EXE is a fine shareware program designed by Lloyd Miller in
Canada, a year or two ago. It is a public key encryption program
and can be used (at least SWE used it) to decrypt files encrypted by
the AIDS trojan. It is available on many BBS's and Lloyd runs a FIDO
BBS in Canada.It is available at [phone] as CRYPT.ZIP

Start off using 13 digit (numbers not characters) decryption keys.
Three of the digits will be the major and minor numbers of your DOS
version. For example DOS 4.01 would be 401, etc; Two of the digits will
be the last two digits in the length of command.com if it was on the
disk when stage two was triggered.

It is not yet known what is used for these two digits if command.com
was not present.

Hope this helps somewhat!

------------------------------

Date:    19 Dec 89 07:24:21 +0000
From:    [e-mail] (Jim Wright)
Subject: Re: AIDS Trojan Update (PC)

[e-mail] writes (on behalf of John McAfee):
|       Our investigation has turned up surprise: PC Cyborg
| Corporation has indeed been registered in the country of Panama.

Is anyone aware of any attempts to actually *pay* for these disks?
I'm curious as to what sort of response this would meet.  Also, is the
information on these disks of any worth, or can one claim the "AIDS
information" is just a ploy to propagate a Trojan?  Perhaps this is
really a monumental blunder in the name of copy protection.

Jim Wright
[e-mail]

------------------------------

Date:    Tue, 19 Dec 89 00:29:59 -0800
From:    [e-mail]
Subject: AIDS Trojan Update #4 (PC)

A forward from John McAfee:
==========================================================================

        It's now reasonably certain that there exists only one version
of the AIDS Trojan that has been mailed so far.  All copies that have
been reported so far (31) have the same file size - 146188, date -
9-28-89, and time - 4:28 P.  File compares have been performed on nine
of the 31 samples and they compare exactly.  All have been programmed
in Microsoft Quick Basic Version 3 and none have padding bytes at
either end of the program.  The samples have been taken from England,
Germany, Sweden, Finland, France and the one reported case in the U.S.
Diskettes from two different mailing lists were included in the
sample.
        The significant reported contradictions in the behaviour of
the trojan now appear to be cleared up.  The difference in the
reported activation trigger is now known to be caused by the varying
inputs to the AIDS Information program when it is executed.  The
Information program modifies the count field according to the final
"score" on the quiz.  Those who fall in the high risk categories are
given the most time; those whose answers place them in low risk
categories have their count fields decremented substantially.  If the
AIDS program is never executed, the user has 90 reboots before
activation.
        The reported differences in the occurance of the SHARE.EXE
program after activation are now known to be caused by differences in
printer configurations and printer status.  If no printer is attached
to LPT1, or if the printer is turned off after the initial activation,
no SHARE.EXE program of share message is produced.
        The encryption of the file names and extensions is now also
known to be constant for all samples.  There is no encryption key or
encryption algorithm.  The file names are modified by using a simple
character substitution which is constant for all samples and execution
environments.  The extensions are likewise substituted.  For example:
All COM files are given the extension AK, EXE files are changed to AU
and BAT files are changed to AG.  If a file extension is unknown to
the trojan, then it leaves the extension as is.  Disappointingly
trivial, considering the complexity of the remainder of the trojan
code.
        It is also known now that the INSTALL program will place and
activate the time bomb with or without the accompanying AIDS program.
This seems to imply that the install program may have been written for
additional purposes.  Watch out for potential additional mailings
covering completely different subject matter.

John McAfee

------------------------------

Date:    19 Dec 89 09:19:37 +0000
From:    [e-mail] (Brian Bartholomew)
Subject: Legal Ramifications of PC-Cyborg License

I too would like to hear the opinions of a competent legal counsel
regarding the legality of PC-Cyborg's actions.  I feel that the
current crop of microcomputer licenses bear more resemblance to the
screenplay for a con job, than a contract describing a reasonable use
of a product for a reasonable compensation.  For a long time, there
have been laws in effect that state that a product purchased should
perform in a manner similar to the way that it is advertised.  A
article of machinery purchased as a "car" should perform at least
minimally as a "car".  In the absence of pride, responsibility, and
craftsmanship on the part of the maker, the law should be written to
protect the consumer; a license disclaiming all connection with the
product except the collection of profit does not do this.  Law is like
programming; the media the artist works in is the imagination, and
vision is only limited by the limitations that are inherited from
history.  Make the law serve the people, not the lawyers.

"Any sufficiently advanced technology is indistinguishable from a rigged demo."
-
 -------------------------------------------------------------------------------
Brian Bartholomew       UUCP:       ...gatech!uflorida!beach.cis.ufl.edu!bb
University of Florida   Internet:   [e-mail]

------------------------------

Date:    Tue, 19 Dec 89 10:49:33 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: The missing viruses (PC)

A few PC viruses have been reported but not made generally available
to the virus research community. The "missing" viruses are listed
below. If anyone can confirm the existence of any of them, I would
appreciate it.

2730. It seems that this "virus" does not exist.

Agiplan. This virus was described in a W-German newspaper. It is a bit
        similar to the "Zero-Bug" virus. Both add 1536 bytes to the start
        of .COM programs they infect.

Fallboot. A BSV that is reported by the VIRSCAN program from IBM. Produces
        a display similar to that produced by 1701/1704.

Missouri, Nichols. Two boot sector viruses that were reported by
        McAfee/Homebase, but are not included in a recent list by him.

Screen. Reported by Ross Greenberg, it may be just a variant of the South
        African virus. Ross said it was uploaded to his BBS earlier this
        year. He described it in an article in BYTE.

Jerusalem variants. Of the 13-14 different Jerusalem variants, only five
        are "available".

Palette. Adds 1538 bytes to .COM files.

In addition the following viruses have been mentioned, but probably they
do not exist:

Cookie. .COM infector

Retro

Hyperspace

The rest of the PC viruses is probably in the hands of most virus researchers
by now.

- -frisk

------------------------------

End of VIRUS-L DigestVIRUS-L Digest   Wednesday, 20 Dec 1989    Volume 2 : Issue 265

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Internet Worm Program
Legal Implications of the PC Cyborg Mailing
AIDS disk analogies (PC)
Re: WDef and Gatekeeper Aid.
Signature Programs
Gatekeeper and Gatekeeper Aid (Mac)
DES Availability
SWE HAS MOVED TO A NEW ADDRESS
Re: AIDS Trojan (PC)
Re: AIDS Trojan Update (PC)
Was AIDS disk legal?
AIDS Information Disk (PC)
Standard disclaimers and AIDS Trojan horse

---------------------------------------------------------------------------

Date:    Thu, 14 Dec 89 14:53:53 +0000
From:    mitel!sce!cognos!alzabo![e-mail] (Tris Orendorff)
Subject: Internet Worm Program

        Internet Worm Update ...

        According to 2600 Magazine,

        If you want a copy of the source code (with comments), send $10
        to 2600 Worm, PO Box 752, Middle Island, NY 11953

                                Sincerely Yours
                                Tris Orendorff
                                [e-mail]


------------------------------

Date:    Tue, 19 Dec 89 11:00:00 -0500
From:    Jim Shanesy <[e-mail]>
Subject: Legal Implications of the PC Cyborg Mailing

Since it contained the greatest amount of information regarding
licensing, payment, what it purported to be, etc.  than the other
postings, I have sent Mr. McAfee's first alert re this Trojan Horse to
a dear friend, Paul R. Paletti, Jr., Esq.  of Handmaker, Citrynell &
Assoc. in Louisville, Ky.

Mr. Paletti is a licensed, practicing attorney-at-law who is also a
computer enthusiast.  He uses his PC in his work, downloading cases
from LEXIS via modem.

When he has time to read my fax, we'll confer by phone and I'll send
his opinions to this discussion list.  Since copyright and patent laws
are federal ones, he should be as qualified as anyone to assess the
legal ramifications of this catastrophe.

Jim Shanesy
Office of Computer and Information
Technology
National Research Council
2101 Constitution Ave., NW
Washington, DC  20418
(202)-334-3219

------------------------------

Date:    19 Dec 89 11:07:00 -0800
From:    [e-mail]
Subject: AIDS disk analogies (PC)

In reading the analogies pertaining to the AIDS Virus, I could not
help but be struck by some parallels between the computer virus and
the actual virus.  First, like AIDS, some people are struck down very
quickly while for others there is a long incubation process.  Second,
once you find out that you have it, you must be prepared to spend
large sums of money to combat it on a recurring basis.  Third, lots of
warnings are given about the virus, what will happen if you utilize
the disk (engage in risk behavior) but many people ignore these
warnings and are thus infected.  Fourth, the Virus comes from Africa,
the probable birthplace of the actual AIDS virus. Fifth, there is no
guarantee that paying your money will produce a cure, or that one cure
actually exists (tailoring vaccine to specific machines/people).
Sixth, the hysteria surrounding the VIRUS is both making people more
aware of viruses in general and prompting much research into finding a
way to decrypt the initiating factor.  Seventh, there seems to be more
we don't know about the Virus than we do know.  The initial effects
have been diagnosed and a remedy for the symptoms found but long term
effects are still unknown.

Perhaps I am seeing too much in this, but given the enormous outlay of
both time, energy and money that someone went through; perhaps the
perpetrators of this virus are attempting to give us all a non-lethal
lesson as to what the real virus AIDS is all about.  I am not
justifying their actions but I just can't help but wonder if that
lesson is what all this is all about.  It would, to me, clarify the
use of AIDS Information as the method of transmission.

Comments, anyone

------------------------------

Date:    19 Dec 89 19:30:03 +0000
From:    coherent![e-mail] (Dave Platt)
Subject: Re: WDef and Gatekeeper Aid.

[e-mail] (Gregory E. Gilbert) writes:
> I booted some Macs with Gatekeeper Aid installed this AM.  I was
> immediately presented with a rather sharp looking dialog announcing
> that the "Implied Loader ABDS" virus(?) was found and removed.
>
> Is this the Wdef virus?  If so, why not call it such AND what is an
> "Implied Loader ABDS".

The "ADBS" resource in the Desktop file is almost certainly not a virus.
Rather, it's the signature for the Adobe Separator application.

Unfortunately, "ADBS" is one of the resource-types that Apple has
reserved for its own use... per Inside Mac V, resources of this type
hold code which acts as an interface to the Apple Desktop Bus and its
devices (keyboard, mouse, etc.).  Because this resource-type can contain
executable code, Gatekeeper Aid considers that it shouldn't be in the
Desktop file.

I don't know how a commercial application ended up with a signature-
resource that's identical to one on Apple's list of reserved types.
there are several ways in which this could have happened... all of
which would appear to involve a bit of an oversight on someone's part.

Removing this particular resource from the Desktop file might have some
adverse effects on the Adobe Separator application.  In particular, I
might expect to see its documents revert to the generic icon, and you
might not be able to double-click on a Separator document and launch the
application.

I believe that Chris will be updating the documentation for Gatekeeper Aid
to warn of this problem.
- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    19 Dec 89 13:01:54 -0500
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

In his mailing of Dec 07 '89, Y. Radai seems to be taking the position
that since I am in favor of sophisticated authentication algorithms, I
must be against sophisticated program implementations. Nothing could
be further from the truth. A really reliable virus detection program
must have BOTH a trustworthy authentication algorithm and a
sophisticated implementation. I stressed the importance of
sophisticated authentication algorithms only because as a newcomer to
VIRUS-L, I was seeing a lot more discussion of implementation details
and scanner programs than of quality authentication techniques.

Please don't misinterpret me: PROGRAMS THAT PURPORT TO DEFEND AGAINST
VIRUSES MUST BE EXTREMELY CAREFULLY WRITTEN. In my view, they should
use the best and most sophisticated defenses available. Today, that
means authentication algorithms should be based on published standards
that have stood the test of time, such as ANSI X9.9. Obviously if a
clever virus writer is able to orchestrate a situation in which the
virus is never examined, then even a sophisticated authentication
algorithm is of no use.  What is needed is a well-written and
convenient program that applies a sophisticated authentication
algorithm across all program code without exception. Clearly this is
better than a well-written and convenient program that applies some
programmer's guess at an authentication algorithm across all program
code without exception!

The address where copies of ANSI X9.9 can be obtained didn't make it
into my last posting. Sorry about that. Copies of ANSI X9 standards
can be obtained through:

Secretariat: American Bankers Association
             Standards Department
             1120 Connecticut Avenue, N.W.
             Washington, D.C. 20036

I think the price is $15.00. I bet if you send a check and a mailing
label with your return address on it, you'll get quick response.

- -Bob Bosen-
Vice President
Enigma Logic Inc.
[e-mail]

------------------------------

Date:    Tue, 19 Dec 89 17:30:00 -0500
From:    "Carl_A.Fassbender" <[e-mail]>
Subject: Gatekeeper and Gatekeeper Aid (Mac)

In Michigan State University's public laboratory, we have run into
many viruses including the WDEF virus.  We decided to put Gatekeeper
and Gatekeeper aid on our system disks.  To protect these files from
being erased, they were made invisible using MacTools.  Now in the
control panel, the Gatekeeper icon does not show up.  Question: Does
this mean that Gatekeeper is not active?  What about Gatekeeper Aid?

------------------------------

Date:    Tue, 19 Dec 89 21:14:24 -0500
From:    Steven C Woronick <[e-mail]>
Subject: DES Availability

IA96000 <IA96@PACE> (name unknown, employee of "SWE"?) writes:

>SWE first suspected and tested for the public key encryption method
>for several reasons. The major reason was the lack of access people
>outside of the United States would have to the DES encryption formula.
>
>For those not aware, the U.S. Government guards the DES formula, and
>software which makes use of this formula may not be exported out of
>the United States. Should it turn out that the DES formula was also
>used, the authors of the AIDS "trojan", could possibly be prosecuted
>under United States statutes pertaining to national security.

   Please correct me if I'm wrong, but isn't DES or DES-like
encryption algorithms readily available?  For example, the book
"Numerical Recipes, The Art of Scientific Computing," by W.H. Press,
B.P. Flannery, S.A.  Teukolsky, and W.T. Vetterling, published by
Cambridge University Press, (c)1986, p. 214-220 gives an algorithm for
DES (two and one half pages of highly-inefficient FORTRAN-like code).
Admittedly, the authors state that their program is not genuinely DES
(since the standard itself explicitly states that any implementation
in software is not secure and therefore not DES), but it does in
software the same thing real DES hardware would do, so it is for all
practical purposes DES.  (Also, how does the claim that software
versions of DES are technically not DES affect legal issues raised by
IA96000@PACE about exporting DES?).  Also, in my opinion, there is
nothing special about DES except that it is a kind of "standard"
algorithm (i.e. I think one can easily imagine other
equally-difficult- to-decrypt algorithms).

Steven C. Woronick     | Disclaimer:  These are my own opinions.
Physics Dept.          |     Always check it out for yourself...
SUNY at Stony Brook    |
Stony Brook, NY  11794 |
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

Date:    Tue, 19 Dec 89 20:55:00 -0500
From:    IA96000 <[e-mail]>
Subject: SWE HAS MOVED TO A NEW ADDRESS

This is the final forward from SWE.

Please be advised due to  employment opportunities SWE is now in
the process of moving to a new location. They no longer have any
contact with Bitnet at this time.

They can be reached via US MAIL at the following address:

SWE
C/O General Delivery
Orlando, Florida

To those who requested copies of the AIDS disk, SWE regrets to inform
you the disks they had been working with have been returned to the
customers who sent them.

END OF MESSAGE

------------------------------

Date:    Wed, 20 Dec 89 07:07:30 +0000
From:    [e-mail] (Craig Harmer)
Subject: Re: AIDS Trojan (PC)

[e-mail] (David Gursky) writes:
>The AIDS Trojan Horse discussed by Alan Jay and John McAfee raises some
>interesting questions about accountability.
>
> ... could the perpetrators be held liable under U.S. law for
>damages, when the licensing notice clearly states the program is not
>licensed to be used in the United States, and that damage will result
>if you attempt to do so.

actualy, the licensing notices reminds me of the popular "shrink-wrap"
licenses where by breaking the shrink-wrap, you agree to the terms of
the license.  making the necessary action "running the program" doesn't
seem much different to me (though i'm not a lawyer).

so, assuming the people who's machines have been struck are in violation
of a "legally enforceable" licensing agreement, is the destruction of
data or denial of servicesomething they can sue over?  some of the
purveyors of data-block protection schemes for PCs seem to have provisions
that cause the program to stop working if monthly payments aren't made.

a friend of mine points out that there are also "good faith" types of
clauses in the law that hold that given the method of distribution,
the license agreement would not be valid.  it would be highly interesting
to see the PC Cyborg Corp. sue afflicted PC owners for breach of license!

{apple,amdahl}!tolsoft!craig                            [e-mail]
[phone] (h)                                      [phone] x220 (w)
        [views expressed above shouldn't be taken as Tolerants' views,
                or your views or my views.  they are facts!]

------------------------------

Date:    20 Dec 89 11:24:34 +0000
From:    [e-mail] (Julian ANIGBOGU)
Subject: Re: AIDS Trojan Update (PC)

[e-mail] writes:
>A forward from John McAfee:
>
[deleted]
>The directors are: Kitain Mekonen, Asrat Wakjira and Fantu Mekesse. Since the
> names of the directors are all West African, it appears that the story told
>by Ketema Corporation about representing a Nigerian software firm may be
>close to the truth.  The story unfolds.
>[rest deleted]

I would like to correct the impression your assertion creates. That is
that the AIDS virus is from Nigeria. The names are quite exotic but as
a Nigerian I'd like to inform you of a fact you neglected: that the
names might be false . Well, Well, Well: the NAMES are all FALSE. We
don't answer such names. As a regular user of the PC, just as I would
like you to get to the bottom of this problem because it's a real
international problem, I would like you to be objective. Somebody
somewhere is/are covering his/their track(s) by stringing a red
herring.

Doesn't the name Mekonen remind you of a personality in Startrek?

I'm ready to be flamed but I can assure you that the above names are
fictitious. We certainly have not come of age in Computer Science to
produce such destructive weapons. It's obvious that some malefactor
somewhere is hiding under certain names to do his/their evil deeds.

Julian
                                ---------------------------------------
e-mail: [e-mail]  | All opinions expressed here are      |
                                |  naturally mine. However ...         |
                                ----------------------------------------

------------------------------

Date:    Wed, 20 Dec 89 11:30:09 +0000
From:    [e-mail]
Subject: Was AIDS disk legal?

Martin Ward is quite right to say that:

>the effects of this disk are entirely in accordance with the standard
>warrenty used by most commercial software developers

however, I do not think that makes it legal.  Firstly there is the
question of blackmail.  This can mean either making an impropor
demand, or using impropor means to enfore a legitimate demand.  While
it could certainly be argued that they are quite within their rights
to demand payment, and could reasonably disable their own program
until such payment was made, I would hope that planting a logic bomb
that encrypted all the user's other files would not be considered a
propor means of enforcing that demand.

Secondly, there is criminal damage.  This is trickier, since although
a great deal of damage was certainly done, technically the program
acts in full accordance with the information given in the warrenty.
Furthermore, it is obviously not illegal to sell programs that can
wipe your hard disk (eg. Norton, or most other disk utilities).  I
suspect that the issue might come down to one of causality: By writing
the program, did the authors (legally) CAUSE the data to be lost , or
was the chain broken by a voluntary act on the part of the user.

Again, my hope would be that the former is the case.  The authors
almost certainly knew that most users would try out the program
without reading, or without fully comprehending the implications of
the warrenty.  They were tricking the users into executing the
program, and the users were behaving in a perfectly natural and
predictible manner.

Please note that I am not saying that every piece of defective
software is a case of criminal damage: if you write a program in good
faith, the element of mens rae does not exist (though that would not
protect you against a civil or criminal action for negligence).  In
this case, though, I think it quite reasonable to conclude that the
authors almost certainly acted with malicious intent.

DISCLAIMER: I am a Astronomer, not a Lawyer.  The above information is
not warrentied for any purpose whatsoever.

- --------------------------------------------------------------------------
Graham Shaw, Physics Department, Durham University, ENGLAND.  091-374-2138
JANET: [e-mail]          EARN: G.D.Shaw%MTS.DUR.AC.UK@UKACRL
INTERNET: [e-mail]      STARLINK: DUVAD::GDS
- --------------------------------------------------------------------------

------------------------------

Date:    Wed, 20 Dec 89 10:21:13 +0000
From:    Alan Jay <[e-mail]>
Subject: AIDS Information Disk (PC)

> From:    Martin Ward <[e-mail]>
>
> I feel that I should point out that the effects of this disk are
> entirely in accordance with the standard warrenty used by most
> commercial software developers

Though most of them don't blatently say "if you don't I will destroy you."
(see below)

> (the ones which disclaim that the
> programs are fit for any purpose at all, that XXX will disclaims all
> responsibility for any damage or loss caused etc.)

This is the kind that implies that if by mistake I do something that
causes a problem tuff (in the US I believe several companies are
trying to reclaim money caused by losses resulting from bugs in
spreadsheet software).

> Either these
> warrenties are ILLEGAL or the perpetrators of this disk are entirely
> within their legal rights to do what they have done. Does anyone (eg a
> lawyer) know which is the case?

Martin's point is interesting but worse still the warranty and license
agreement sent out with the AIDS Infromation Disk specifically state that:
"Warning: Do not use these programs if you are not prepared to pay for them''
and
"..program mechanismis will adversely affect other program applications...''
and
"..faliure to abide by this license......your conscience may haunt you for
the rest of your life ....... your microcomputer will stop functioning
normally."

Generally if you read the license agreement you would NOT use the program.
The legallity of the license is questionable but probably no more so than
the comercial one described by Martin.  At one time several reputable
software companies were rumered to have been contemplating using
a copy protection scheme that would have caused damage and data loss if the
program was illegally copied.  Luckily for us Software houses went the
opposite way to a non copy protected world.

Maybe this is nothing more than a copy protection scheme that isn't
quite as good as it is supposed to be -- it has bugs that cause it to go
off sooner than the anticipated 90days after installation.

An antidote to the two known phases of the program mechanism has already
been written and is available from our BBS ([phone]) and from the
PC Business World (Tel: [phone]).  We are only speculating that
the program does other detrimental things to your system until they are seen
the programs effects appear to be reversable.

Whatever the reason behind this mailing it sould only warn people to remind
ALL users not to use and disk sent to them, especially if it is unsollicited.

Alan Jay

PS If any users have installed the AIDS program then I can mail them the
antidote for it.  Please mail me with your requests.

------------------------------

Date:    Wed, 20 Dec 89 10:50:00 -0500
From:    [e-mail]
Subject: Standard disclaimers and AIDS Trojan horse

In VIRUS-L #261, Martin Ward asks whether the standard warranty is
illegal, or the developers of the AIDS-trojan are within their rights.

I am a programmer, not a lawyer, so I can not quote specific law with
any authority; suffice it to say that the disclaimers that come with
most of the software I buy observe that the liabilities of the
manufacturer or distributor of a program vary between jurisdictions.

However, from the point of view of a programmer, I can point out that
there is a great difference between disclaiming responsibility for the
way a program will behave on any arbitrarily chosen machine, and writing
a program with the deliberate intention of causing harm. Whether a court
would appreciate the difference remains to be seen, but in this case, if
a case can be made that the demand for money the "AIDS" program makes is
extortion, I doubt that any disclaimer could protect the authors.

As for the legal (not to say ethical) question of whether is it is ever
acceptable for a programmer to write a harmful program, there is (or was)
a case that may shed some light on this issue: Eric Newhouse, in his
newsletter on illegal programs, trojan horses, and viruses, claimed that
a "legitimate" commercial outfit had written a trojan horse that claimed
to crack softguard protection on a file, but actually destroyed the user's
data. The claim he reported that the company in question made was that
since an attempt to crack softguard protection was a violation of a
license agreement, they data of such users was fair game. Mr. Newhouse
indicated that the authors of this trojan were being taken to court,
which may (if the issue is through the courts yet) shed some light on
the judicial perception of this issue.

John G. Spragge
Taliesin Software Resources Limited
Suite 212, 4 Cataraqui Street
Kingston Ontario, K7K 1Z7
Phone: [phone], Bitnet: <SPRAGGEJ@QUCDN>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 21 Dec 1989    Volume 2 : Issue 266

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

AIDS Fix - phone no.
Trojan AIDS: the AIDS program (PC)
Re: AIDS disk (PC)
AIDS Information Disk Technical Analysis available
Re: Gatekeeper and Gatekeeper Aid (Mac)
Holiday VIRUS-L/comp.virus interruption
Authentication
Invisible INITs - Don't (Mac)
Re: Gatekeeper and Gatekeeper Aid (Mac)
Artificial Life Workshop - final announcement!
Another AIDS disk recipient (PC)
Flu virus (PC)

---------------------------------------------------------------------------

Date:    20 Dec 89 17:07:18 +0000
From:    [e-mail]
Subject: AIDS Fix - phone no.

The following has been sent to me for forwarding.  The AIDS disk that my
colleague received was 2.00 and arrived when all the others did.  I have
no other information about the AIDS Version 1.0 diskette.

Sam Wilson
Network Planning, Edinburgh University Computing Service

- --- Forwarded message:

Subject:  AIDS Fix - phone no.
From:     G.Toal @ uk.ac.edinburgh
Date:     20 Dec 89  16:00:54 gmt

>From Frank J Leonhardt. fjl@cix aka [e-mail]

Here is some information about the Aids disc, gleaned from research
done in London, which, judging from messages taken from the network
and passed on to me from the Edinburgh Virus BB, you may not be aware of.

There are indeed two versions of the disc. There were a few, sent out
about a month ago, labelled as version 1.0. Most of them are labelled
2.0. The two versions are different.

There is a complete fix program available, which will totally un-
scramble you disc even if the trojan has done it's stuff. Not easy
when you consider how the encryption key was made up (i.e. out of free
memory, date, MS-DOS version and so on). If you need this program you
can get hold of it by 'phoning 01-831 9252 (PCBW offices) and ask for
it. PCBW can also be found in the basement of 99 Grey's Inn Road,
London, and would love some more copies of the discs, especially
version 1.0.

The program to restore a smashed disc is called CLEARAIDS and will
soon be available on "cix" in the conference "virus/files". CIX is a
commercial system which us poor non-academics have to use instead of
Janet. <hint!> [OK Frank - I'll get you an ID. GToal]

Thanks for [e-mail] for getting stuff on and off Janet for this.

Frank J Leonhardt. fjl@cix aka [e-mail]

- --- End of forwarded message

------------------------------

Date:    20 Dec 89 16:36:00 +0100
From:    Klaus Brunnstein <[e-mail]>
Subject: Trojan AIDS: the AIDS program (PC)

The AIDS diskette contains 2 programs,
              INSTALL.EXE   146.188 Bytes   9-28-89     4:28p
              AIDS.   EXE   172.562 Bytes   8-07-89    10:28p

the first of which is described by J.McAfee and others (INSTALL.EXE and it's
installed versions REM,SHARE) in VIRUS-L; this is the Trojan horse.

The AIDS-program itself contains a question/answering session with AIDS-
related question, where a `risk' (on 7 levels) is computed for the specific
answers. While most other groups are analysing the INSTALLed Trojan horse,
one group at Virus Test Center Hamburg actually analyses the AIDS program.

We have run several sessions, and we regard the program as *not very
intelligent* from the Informatics standpoint, and *not highly reliable*
from the medical standpoint (we will prove this with some medical experts; we
received 4 copies from specialists in immunology, and 3 more copies from
banks etc).

The AIDS program works rather linearly; the dialogue is done with simple
multiple choices, where the 1st option is alwys HELP-text. If you analyse the
HELP texts, they are not very specific (many of them may have been generated
from an ordinary lexikon). In section 1, BACKGROUND INFORMATION is gathered,
e.g. residence country, sex, age (in 9 clusters), ancestors origin continent,
sexual behaviour (heterosexual, no sexual experience, homosexual or bisexual),
and number of sex partners since 1980 (in 8 clusters from 0 to 100+)are asked.

In section 2, MEDICAL HISTORY is examined, e.g. how many blood transfusions
since 1980, active tuberculosis, drug injection, sexually transmitted
diseases, sexual habits (use of condom..). For some positive answers,
there may be additional details asked for. No mechanism is visible whcih
safeguards the extensive personal data; on the other side, no data are
gathered which may be used to authenticate a person and relate their name
with the data gathered.

After an evaluation procedure (less than 1 minute on an AT), `you' are
assigned to one of seven Levels of AIDS Risk (`no risk, very low risk,
low risk, medium risk, high risk, very high risk, extremely high risk).
Depending on the list of answers, a PERSONAL ADVICE is given, e.g. stating
`Your risk of exposure to the AIDS virus is low but presently increasing..',
suggesting to use condoms, etc. Finally, you are asked to input YOUR
COMMENTS (`Use the computer like a typewriter. Type anything that comes to
your mind ... The computer will then analyze your remarks and respond to you
with further comments..'). The answers are rather unspecific.

Based on some experiments (with more systematic testing to be done
after having reverse-engineered the code), my best estimation is, that
the question-answering is done in typical BASIC style, and that the
risk evaluation function is only very rudimentary (we received a 'low
risk' for a young female drug addict). The personal advice seems to be
programmed from a few types of answers, and the analysis of Your
Comments fails with even simple, AIDS-related questions.

The 'loose' relation between INSTALL/REM/SHARE and AIDS (probably influencing
the catastrophic counter, evidently initialised at 90 and decremented during
bootup) will very probably allow to use the INSTALL process also *in connection
with other 'interesting programs'*. With so may diskettes distributed, we may
face similar (and maybe more serious) threats. I therefore appreciate
J.McAfee's remark that he has included his ANTI-Trojan in his ANTIVIRUS tool.
Though mixing up an Antivirus Tool with Anti-Trojan functions may produce
new problems (e.g. misunderstanding the respective threats and the limitations
of such tools), I suggest that also other antivirus tools should contain a
diagnostic featrue for Trojan AIDS.

Evaluating the given situation, I conclude that the business procedure (the
e.g. distribution of diskettes) was professional, and that the Trojan horses
mechanisms were rather intelligent, though some parts of the INSTALL/REM/SHARE
are primitively linear programmed, e.g. the `encryption' part. The AIDS
program is of neither good programming nor medical standard.

Klaus Brunnstein
- -----------------------------------------------------------------------
PostAdress:      Prof.Dr. Klaus Brunnstein
            Faculty for Informatics, Univ.Hamburg
                    Schlueterstr.70
                   D 2000 Hamburg 13
           Tel: [phone] / -4162 Secr.
ElMailAdr:   [e-mail]
FromINTERNET:[e-mail]
FromBITNET:  [e-mail]
FromUUCP:    [e-mail]
- -----------------------------------------------------------------------

------------------------------

Date:    Wed, 20 Dec 89 18:33:56 +0000
From:    Phil OKunewick <[e-mail]>
Subject: Re: AIDS disk (PC)

attcan![e-mail] (Richard Meesters) writes:
>[e-mail] (Martin Ward) writes:
>> I feel that I should point out that the effects of this disk are
>> entirely in accordance with the standard warrenty used by most
>> commercial software developers...
>
>...Warranty implies that the
>product was purchased and you are following the terms of the purchase
>agreement.  The trojan runs for a time and then demands that you pay
>for the product...
>  ...kidnaps your data and holds it for ransom.
>
>Illegal, or at least extremely Immoral (presumably the former).

    Illegal in the United States, which may be why they didn't try to
spread it here.

    According to the regulations of the U.S. Postal Service, if you
receive something through the mail which you have not ordered, then
you automatically own it.

    If this were not enforced, then many of these annoying organizations
that send us ads for junk products would instead be sending us the junk
products, along with a bill for their trash.

    Does the U.K. have a similar law?
- --
                                        ---Phil
(erutangis. ruoy naht daer ot redrah si erutangis. yM)

------------------------------

Date:    Mon, 18 Dec 89 11:14:02 +0000
From:    Alan Jay <[e-mail]>
Subject: AIDS Information Disk Technical Analysis available

The following Article was submitted by Alan Solomon for distribution
on CONNECT and USENET.  It relates to the AIDS Information Disk and
gives extensive technical details of the disk and the AIDS program.

This article is 1800 lines long.

Dr Alan Solomon is Chairman of the IBM PC User Group, London.


Alan Jay -- The IBM PC User Group -- PO Box 360, HARROW HA1 4LQ -- 01-863 1191

[Ed. Due to its length, the document has been forwarded to the
comp.virus documentation archive sites.]


------------------------------

Date:    Wed, 20 Dec 89 16:30:16 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Gatekeeper and Gatekeeper Aid (Mac)

In VIRUS-L Digest V2 #265, "Carl_A.Fassbender" <[e-mail]> was
asking why the Gatekeeper & Gatekeeper Aid icon did not show up after
he made the files invisible.

The Mac OS does not load INITs that are part of files with the
Invisible bit set.  [Editorial comment: Hey Apple!  Why?????]  If you
want to have Gatekeeper active, you must have the file visible on the
desktop.

------------------------------

Date:    Wed, 20 Dec 89 16:26:53 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: Holiday VIRUS-L/comp.virus interruption

With the Holiday season approaching, VIRUS-L/comp.virus will be rather
intermittent during the next week.  I will be in the office until
Friday, December 22 and out for the entire next week.  However, I will
be logging in from home periodically and sending out the occasional
digest (as demand dictates).

Remember that urgent messages, as always, can be sent to
[e-mail].  Please do not use VALERT-L for
discussion - VALERT-L was created due to requests from people who wish
to keep up with virus activity only, not discussions.  All followup
and subsequent discussions should be sent to VIRUS-L/comp.virus.

Also, the Computer Emergency Response Team (CERT) can be reached via
email (monitored daily) at [e-mail] or (for more urgent
problems) at 24 hours a day at [phone] for Internet related
security incidents.

Holiday Cheers and Best Wishes to all!

Ken

Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[e-mail]
[phone]  (24 hour hotline)

------------------------------

Date:    Wed, 20 Dec 00 19:89:52 +0000
From:    [e-mail] (Ross M. Greenberg)
Subject: Authentication

Bob Bosen, of Enigma, comments in VL V2#265 further about the need for
X9.9 as the level of sophistication required of an authentication
scheme.

I'm not sure he's right.  Let's look at two different usages for
authentication schemes: one, to determine if a program is what you
expect it to be during a "global" scan, one to determine if the
program is what you expect it to be immediately before it is run.

A subset of the second portion above is whether a program can contain
a self-checker -- a portion that checks itself when it is run.  I
propose that self-checkers, while useful, are meaningless: by the time
a self-checker's checking code is run, the virus or trojan's damage is
already done.  Additionally, what prevents the virus/trojan from
removing itself from the host file and/or memory before the
self-checker runs?  Therefore, self-checking programs are not realy
worthy of further comment.

Case 1, above, when a scanning program checks a file's signature
against a supposed signature is good stuff.  Yet, you must prepare
yourself for a long initial time to build the original authentication
database -- the more complex the scheme, the longer such a check will
take.  There's a commercial anti-virus program out there already that
does some sort of authentication check on every executable on your
disk (PC-based).  On a full disk, it can take something like three
hours to run on an XT machine.  X9.9 might be a good approach, but if
it takes even that longer and not longer, you simply won;t get people
using it -- regardless of how wonderful it is.  If I have to run such
a beast each morning, I'll pass.  I think most commercial users would
bypass a long wait -- they do, after all, have some work to do.

What about a checker that checks only that a file you're about to run
is what you expect, then?  This *may* be worthy of comment (heck, my
own code does that! :-) ), but it depends on how long it takes.  If it
takes me ten minutes to load Word Perfect on my trusty 4.77MHz, run
asophisticated authentication check against it and then finally get to
run it, well, my boss is not going to be too happy. So, the more
sophisticated the algorithm, the less likely it is to be used.  I know
this from my own beta testers for a new release of my own product:
they felt that the more sophisticated checker, although nice and more
trustworthy, simply took too long to run.  Given a choice, and they
make their choices known with their payments, they opt for one that's
"good enough".

What's a programmer to do, then?  My suggestion is easy: forget those
who claim that sophisticated checkers are what we need -- they may be
right, but there are many drawbacks to them, and we all still have
work to do!  Forget those who claim that their solution is the only
solution.  But, I'd rather have two unrelated and unsophisticated
algorithms that the "bad guy" knows nothing about, then one
"unbeatable" algorithm that goes unused.

Since there are umpteen different ways that such checkers could be
written, the odds of two such routines generating the same results
given a change in the source is pretty darned small.  And, if you're
still in doubt, then run a third or forth or 20th checker.....

Ross M. Greenberg

Ross M. Greenberg, Technology Editor, UNIX Today!   [e-mail]
             594 Third Avenue, New York, New York, 10016
 Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  To subscribe, send mail to [e-mail] with "Subject: Request"

------------------------------

Date:    Wed, 20 Dec 89 16:51:15 -0500
From:    Joe McMahon <[e-mail]>
Subject: Invisible INITs - Don't (Mac)

Any file which is invisible will not bec checked for INIT resources.
This means that GateKeeper and GateKeeper Aid are *not working*
because they have not gotten to install their hooks.

System 6.0.2 (I think) was the first System to add this check to the INIT
mechanism; this was done to help combat the Scores virus's famous invisible
"Desktop" and "Scores" files, which contained INITs.

Summary: Make INITs and cdev's invisible, and any INITs they install won't
         work.

 --- Joe M.

------------------------------

Date:    20 Dec 89 22:34:09 +0000
From:    coherent![e-mail] (Dave Platt)
Subject: Re: Gatekeeper and Gatekeeper Aid (Mac)

[e-mail] (Carl_A.Fassbender) writes:
> In Michigan State University's public laboratory, we have run into
> many viruses including the WDEF virus.  We decided to put Gatekeeper
> and Gatekeeper aid on our system disks.  To protect these files from
> being erased, they were made invisible using MacTools.  Now in the
> control panel, the Gatekeeper icon does not show up.  Question: Does
> this mean that Gatekeeper is not active?  What about Gatekeeper Aid?

Apple's System 6.0 and later will not execute INIT resources which reside
in invisible files.  This was done to prevent viruses (e.g. SCORES)
from dropping invisible INIT files into the System folder.  By making
the Gatekeeper and Gatekeeper Aid files invisible, you've rendered them
inoperative.

You can, if you wish, make the whole System folder invisible;  this won't
prevent the system from booting and won't prevent Gatekeeper etc. from
installing themselves.  For lab machines, this is often a reasonable
approach.
- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    20 Dec 89 22:29:59 +0000
From:    [e-mail] (C G Langton)
Subject: Artificial Life Workshop - final announcement!

 FINAL ANNOUNCEMENT !!!!

                            ARTIFICIAL LIFE
                            ---------------

                     A workshop on the synthesis of
                     living and evolving artifacts.


                          February 5-9, 1990
                         Santa Fe, New Mexico

                             Sponsored by
                             ------------

                The Center for Nonlinear Studies, LANL
                                  and
                        The Santa Fe Institute



                            Self-Organizers
                            ---------------

                              Doyne Farmer
                             Chris Langton
                            Steen Rasmussen
                             Charles Taylor

   Artificial Life has only recently emerged as a coherent field of
   scientific research. Its primary methodological approach is to study
   life and evolution by attempting to actually create living and/or
   evolving processes within computers, beakers, or other ``artificial''
   media. Its primary goal is to abstract the ``logical form'' of life
   from its material basis - and to construct a truly general theory of
   living systems, one which will be capable of treating life wherever it
   is found in the universe and whatever it is made of. ``Artificial'' Life
   can contribute to the study of ``real'' life by helping to locate
   life-as-we-know-it within the larger context of life-as-it-could-be,
   in any of its possible incarnations.

   This will be the second workshop on the topic of Artificial Life. The
   workshop will include invited and contributed talks, demonstrations,
   and discussions on the many scientific, technical, philosophical, and
   moral issues surrounding the increasing attempts to synthesize life
   artificially. We will also have an artificial ``4H show'' with prizes
   for the best artificial life-forms.

   Specific investigations in the field of Artificial Life include attempts
   to synthesize, simulate, or otherwise recreate the following:

   - the emergence of autocatalytic sets within soups of artificial polymers;

   - the evolution of strings of code using Genetic Algorithms;

   - self-reproducing bit-strings, clay-crystals, RNA molecules, or LEGO-robots
;

   - the emergence of cooperativity, colonial organization, multi-cellularity,
       and hierarchical organization;

   - the embryological processes of growth, development, and differentiation;

   - the emergence of social behavior in populations of artificial insects;

   - the emulation of population and ecosystem dynamics;

   - the implementation of artificial environments, logical universes,
       or ``virtual realities'' sufficiently rich to support the open-ended
       evolution of embedded ``organisms'';

   - cultural evolution, including the origin and evolution of socio-
       cultural institutions, and the evolution of natural language in its
       role as a vehicle for cultural inheritance;

   - the dynamics of self-propagating information structures such as
       biological and computer viruses;

   Many of the investigations mentioned above will be reported on or
   discussed at the workshop.

   We expect that there will also be plenty of debate on the question of
   whether or not symbolic processes within computers can be considered
   ``alive'' in principle, or whether they could be capable of participating
   in anything like truly open-ended evolution. These debates will probably
   parallel to a large extent the debates in the AI community on whether
   processes within computers can considered to be ``intelligent'' or
   ``conscious.''

   We are also encouraging presentations and/or debates on the moral and
   social consequences of achieving the capability to create living things.
   The mastery of the technology of life will easily overshadow any of our
   previous technological accomplishments - even our mastery of the technology
   of death - in terms of the burden of responsibility which it places on our
   shoulders. As was the case for the mastery of atomic fission and fusion,
   the potential abuses are directly proportional to the potential benefits.
   Once again, we are in a position where our technical understanding of nature
   is far in advance of our understanding of the potential consequences
   of mastering or deploying the technology. This is not an enterprise to
   be undertaken lightly, or to be pursued in the cause of such shortsighted
   goals as fleeting military advantage.

   The increasing spread and sophistication of computer viruses is evidence
   both of the imminence of this new era in the history of life, and of the
   complexity of the problems and issues that will be facing all of us in
   the not-too-distant future.

   We welcome your presence and contribution on any aspect of Artificial
   Life that you consider worth presenting or discussing with others
   who are interested in such issues. Whether you are a scientist, an
   engineer, a philosopher, an artist, or just a concerned citizen, we
   feel that ALL points of view need to be aired at this early stage in
   the evolution of Artificial Life.

   For further information and/or registration materials, contact:

                             Andi Sutherland
                         The Santa Fe Institute
                             1120 Canyon Rd.
                          Santa Fe, New Mexico
                                 87501

                              505-984-8800
                          [e-mail]

   The deadline for contributions is Dec. 31, 1989. Registrations for
   the workshop will be accepted right up to the date of the workshop.
   Some limited financial assistance will be available for the truly
   needy.

   The proceedings of the first Artificial Life Workshop, held at
   the Center for Nonlinear Studies, Los Alamos, New Mexico in 1987,
   are available from Addison Wesley: "Artificial Life: The proceedings
   of an interdisciplinary workshop on the synthesis and simulation
   of living systems", edited by Christopher G. Langton, Volume #6
   in Addison Wesley's `Santa Fe Institute Studies in the Sciences
   of Complexity' series. They can be ordered toll free by calling
   800-447-2226. The order codes are:

              Hardback  (about $40) ISBN 0-201-09346-4
              Paperback (about $20) ISBN 0-201-09356-1

------------------------------

Date:    Thu, 21 Dec 89 02:36:00 +0700
From:    MARCO VAN DEN BERG / IRRI <[e-mail]>
Subject: Another AIDS disk recipient (PC)

        Just to complete the picture : at our institute here in the
Philippines we have so far received two copies of the AIDS disk as
well, but neither of them was installed on a user's machine (thanks to
the warnings from this (now) esteemed forum). Please note that it is
extremely likely that many folks in international organizations (UN,
World Bank, etc.) will be sent this disk when they have ever dropped a
business card at some computer show.

        By the way, I *really* think the US reaction is a little
overdone, I'm sure that Noriega doesn't even know a keyboard from an
M16...

Marco van den Berg
International Rice Research Institute
Los Banos
The Philippines
[e-mail] or [e-mail]

------------------------------

Date:    Thu, 21 Dec 89 10:46:26 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Flu virus (PC)

I just received a message from Australia, describing "Flu", a new
virus, that uses a good deal of self-modifying code. Does anyone have
more information ?

- -frisk

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 22 Dec 1989    Volume 2 : Issue 267

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

CERT Anonymous FTP available
Re: Gatekeeper and Gatekeeper Aid (Mac)
1st Aid Software vs. WDEF (Mac)
More information about virus hearing and CPSR statement
Beware of AIDS fixes
Motivations & Trends
Finding the source of the "AIDS disk"
New anti-virus and anti-trojan programs at SIMTEL20

---------------------------------------------------------------------------

Date:    Thu, 21 Dec 89 11:39:40 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: CERT Anonymous FTP available

An additional archive site is now available via Anonymous FTP.  The
machine, cert.sei.cmu.edu, carries a complete set of all CERT
advisories to date, the complete (unabridged :-) set of
VIRUS-L/comp.virus archives, as well as several virus documents.

VIRUS-L/comp.virus information is in:

  ~ftp/pub/virus-l/archives
  ~ftp/pub/virus-l/archives/predigest
  ~ftp/pub/virus-l/archives/1988
  ~ftp/pub/virus-l/archives/1989
  ~ftp/pub/virus-l/docs

CERT advisories are in:

  ~ftp/pub/cert_advisories

This information is made available as a public service.  Submissions
to the documentation collection are welcomed, appreciated, and should
be sent to [e-mail].

Regards,

Ken

Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[e-mail]
[phone]  (24 hour hotline)

------------------------------

Date:    21 Dec 89 16:51:03 +0000
From:    bgsuvax![e-mail] (William C. DenBesten)
Subject: Re: Gatekeeper and Gatekeeper Aid (Mac)

[e-mail] (David Gursky) writes:
> In VIRUS-L Digest V2 #265, "Carl_A.Fassbender" <[e-mail]> was
> asking why the Gatekeeper & Gatekeeper Aid icon did not show up after
> he made the files invisible.
>
> The Mac OS does not load INITs that are part of files with the
> Invisible bit set.  [Editorial comment: Hey Apple!  Why?????]  If you
> want to have Gatekeeper active, you must have the file visible on the
> desktop.

Older versions of the system did not do this.  Apple started this
practice shortly after scores hit the mac.  The reasoning is that
there were if all inits had to be visible, then viruses would have a
harder time hiding from the user.  I believe this to be a good
decision.

On lab disks, I set the entire system folder invisible, but leave the
files visible.

N.B. this is my interpretation and recollection of timeframes.

- --
William C. DenBesten   is   [e-mail]  or   [e-mail]

------------------------------

Date:    21 Dec 89 12:32:00 -0500
From:    "WARTHMAN" <[e-mail]>
Subject: 1st Aid Software vs. WDEF (Mac)

In VIRUS-L Digest V2 #261, John Norstad writes:

> Unfortunately, when the WDEF virus first appeared, none of the
> current versions of the most popular virus prevention tools were
> able to detect or prevent WDEF infections. This includes Vaccine
> 1.0.1, GateKeeper 1.1.1, Symantec's SAM Intercept 1.10, and HJC's
> Virex INIT 1.12.

Although it may not be one of "the most popular virus prevention
tools", I wish to point out that the Anti Virus Kit published by 1st
Aid Software was able to detect the WDEF virus without modification to
the software or to a resource list. The VirusGuard component of the
package is a cdev which, like SAM Intercept, puts up an alert any time
a suspicious activity is atempted. Unlike SAM Intercept and the other
virus prevention tools, VirusGuard was not fooled by WDEF's attempt to
bypass the protection.  This is an important characteristic of the new
virus. WDEF appears to be a new generation of virus which not only
tries to hide from humans but also goes to some length to hide from
anti virus software. The war is escalating...

I beleive that 1St Aid Software in general, and Bob Reese in
particular, deserve some recognition for being the _only_ tool to
successfully handle WDEF. In fact, if this package was more widely
used perhaps WDEF would have been caught sooner and would have spread
far less than it appears to have...

1St Aid Software can be contacted at [phone]. Bob Reese can be
reached via:
   Compuserve 71141,3061
      Applelink D3791

Disclaimer: I have no connection with the company or the products,
aside from being a satisfied user.

                           -- Jim Warthman

------------------------------

Date:    Wed, 20 Dec 89 17:06:21 -0800
From:    <[e-mail]>
Subject: More information about virus hearing and CPSR statement

I've received several requests for the CPSR statement and for more
information about the computer virus hearing.  Please send this
message along to other networks.

The House Judiciary Committee hearing on computer virus legislation
will be aired on C-SPAN on Saturday, December 23 (8:45 am to 11:00 am
EST) and Sunday, December 24 (1:30 am to 3:35 am EST).  For more
information, contact C-SPAN at 202/628-2205. The date of the original
hearing was November 8.

The witnesses included two members of Congress, and representatives
from NIST, ADAPSO, CBEMA, and CPSR.

The prepared statement of CPSR is available from the Washington Office
of CPSR for $5 to cover copying and postage.  The complete statement
is 26 pages long and contains detailed notes about the virus
controversy and computer security policy.  A short summary (about 10k)
is available by e-mail.  If you would like either version, please send
me an e-mail note and indicate your choice.  For the complete
statement, I need your US mail address.

Best holiday wishes,

Marc.

Marc Rotenberg, Director
Washington Office CPSR
1025 Connecticut Ave., NW
Suite 1015
Washington, DC 20036
202/775-1588 (voice)

cdp![e-mail]
[e-mail]

------------------------------

Date:    22 Dec 89 05:53:51 +0000
From:    [e-mail] (Gene Spafford)
Subject: Beware of AIDS fixes

I've been reading a lot of the traffic about the AIDS trojan disk.
I've noticed that a number of places are claiming they have programs
that "fix" your disks and/or watch for reinfection.

I don't mean to impugn any of those efforts, but let me sound a few notes
of caution about these, as with any security software you are offered:

1) How do you know they work?

2) How do you know they don't have bugs that might trash your system?

3) How do you know that they aren't introducing some other trojan or
virus into your system while cleaning up something else?

In particular, #3 concerns me.  Suppose the authors of the AIDS trojan
are out there, and have created a "fixer" program that cleans up the
AIDS problem but plants a new and far more damaging trojan on the
victim's disk.  Just think -- everyone is in a panic about the AIDS
bit, so they jump at the opportunity to get a fix.  Just think how
much more wide-spread the result might be than the original AIDS
problem.  Furthermore, since a fix might have to write to system files
and do special operations, warning messages from virus monitors like
FluShot+ might be ignored by users as these fixes are run.

Of course, #2 is a problem, too.  Buggy software is all too common,
especially when it is written under pressure.

Be very sure you know what you're running.  If you don't get source
code and build it yourself, be sure to ask yourself how you know it is
doing what you think it is.
- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    22 Dec 89 06:19:13 +0000
From:    [e-mail] (Gene Spafford)
Subject: Motivations & Trends

At various seminars during the past few months, I've been making a
few statements about the motives behind viruses and related threats
(like the AIDS diskette).  I'd like to share them with this audience,
too.  I hope I'm wrong about these, but....

Theorem #1)  The majority of viruses written so far have been done for
"sport," by people who have been trying to prove that they can write
viruses.  Others are possible experiments that got away, and a few
specific cases of revenge.

Theorem #2) Within a year or so, writing viruses for "sport" will
almost cease to happen.  They are becoming so well known and such a
nuisance, and software guards are such that casual attempts will not
be tried nor will they be successful if tried.

Theorem #3) We will see more cases of viruses, etc. written as acts of
political terrorism and as acts of extortion.  Examples of
politically-related computer attacks have occurred recently: the
Stoned (New Zealand) virus, the Dukakis Mac virus, the FuManchu virus,
the NASA "wank" worm, and perhaps the current AIDS trojan horse.
These will be much more cleverly written and well-funded attacks as
time goes on.  (Imagine viruses that flash messages like: "Experiment
with Computers, not Animals," "Save the Unborn," "Ban Nuclear Power,"
"Free Palestine," etc.)

Theorem #4) Within the next few years, there will be at least one
major problem where some purported anti-viral/security software will
be made available, and it will contain a logic bomb or trojan horse in
it that causes more damage than what it is supposed to fix.  (Minor
thesis: the likely author of such software will be someone marketing
commercial security software, and the logic bomb version will be a
public-domain package not traceable to the author.  The purpose -- to
discredit public domain anti-virus software.)

Theorem #5) Too many people will continue to seek a software solution
even though the problem is only partially in software.  Thus, we
aren't going to see an end to the problem for a long time to come.

Comments?  Discussion?
- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    Thu, 21 Dec 89 23:55:53 -0800
From:    [e-mail]
Subject: Finding the source of the "AIDS disk"

      It may yet be possible to trace this thing.  The perpetrators
probably didn't plan on the U.S. invading Panama.  If the appropriate
authorities in the UK make the proper requests of the US while there
are still 24,000 US troops in Panama, the needed information might
be extracted.
                                        John Nagle

------------------------------

Date:    Thu, 21 Dec 89 14:18:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: New anti-virus and anti-trojan programs at SIMTEL20

I have uploaded the following files to SIMTEL20, obtained from the
HomeBase BBS:

pd1:<msdos.trojan-pro>
AIDSOUT.ARC     AIDS Trojan remover, use after SCANV
A-VIRUS1.ARC    Information on AIDs Trojan
SCANRS52.ARC    Resident virus infection prevention program
SCANV52.ARC     VirusScan, scans your disk for 56 viruses

- --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 22 Dec 1989    Volume 2 : Issue 268

Today's Topics:

Re: Virus trends
WDEF virus infects Lehigh (Mac)
WDEF / Apology to Mainstay Software (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

[Ed. You may notice a slight format change here - the Topics are
listed before the "boilerplate".  This was suggested to make browsing
the subject lines easier.  Goes to show you - some people only read
articles with interesting and informative Subject: lines...

"That's the news and I am out of here." - Dennis Miller, SNL]

---------------------------------------------------------------------------

Date:    Fri, 22 Dec 89 09:37:04 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Virus trends

I wish to take issue with Gene Spafford's Theorem 4:

"Theorem #4) Within the next few years, there will be at least one
major problem where some purported anti-viral/security software will
be made available, and it will contain a logic bomb or trojan horse in
it that causes more damage than what it is supposed to fix.  (Minor
thesis: the likely author of such software will be someone marketing
commercial security software, and the logic bomb version will be a
public-domain package not traceable to the author.  The purpose -- to
discredit public domain anti-virus software.)"

This assumes the unavailability of high-quality PD/Shareware/Freeware
anti-electronic vandalism software, or rather, that at a certain
point in time, such software will not be available (i.e. the existing
software will be outmoded, as say Interferon is).  It also assumes the
author is able to completely cover his or her steps, as Spaf does
correctly point out, but I would counter that this is harder than it
seems.

Consider the current situation.  Of the PD/SW/FW tools in use today
(FluShot Plus, Gatekeeper, Disinfectant, et. al.), their authors are
well known, and it is well known when they release new copies of their
software.  Any Trojan Horse masquerading as a tool against electronic
vandalism would therefore have to be as good as these tools, and would
probably have to be much better.  Otherwise, people will simply keep
using what they are using (look at how many people still use
Interferon!)  If people are not going to easily switch from one
PD/SW/FW to another, there is an inherited limiting factor on the
"effectiveness" of a Trojan Horse implanted in anti-electronic
vandalism tools.

Furthermore, the code hiding the logic bomb will have to persist in a
large number of unknown user configurations.  Look at the new WDEF
virus on the Mac.  It is simply incompatible with the new Mac IIci,
and it doesn't like the IIcx or any Mac with 8M of RAM that much
either.

I would worry much more about the following:

"Theroem 6": As the trend towards open systems continues, where a
given programming environment can exist over several platforms
(Examples: Smalltalk/V under the Mac OS and Presentation Manager,
X-Windows, etc), instances of machine dependant vandalism will
decrease, and environment dependant vandalism (example: The Dukakis
Hypercard Virus) will increase.  The power of the specific machine's
operating system will be easier to access through these programming
environments, opening up these systems to a larger number of people,
and consequently to a larger number of vandals.

------------------------------

Date:    Fri, 22 Dec 89 00:00:00 +0000
From:    "Rich Silvius" <[e-mail]>
Subject: WDEF virus infects Lehigh (Mac)

We discovered the WDEF A virus on each of the five Mac computers in
our User's Area.  Two of the Macs also had nVirA.  Disinfectant 1.5
was used to successfully clean up both viruses.  We posted signs in
the User's Area and a system bulletin on our Network Server [Ed. IBM
mainframe] to notify the campus community. We had a small reoccurrance
the next day, but for now, all is well.  Other labs were notified
about the WDEF virus and given Disinfectant.  It also showed up in the
Ed Tech lab of the University.


------------------------------

Date:    Fri, 22 Dec 89 12:51:35 -0500
From:    [e-mail]
Subject: WDEF / Apology to Mainstay Software (Mac)

I have a major public apology to make to 1st Aid Software.  I just
learned that their product Anti-Virus Kit is effective against the new
WDEF virus, and I have been saying that "none of the popular virus
prevention tools were effective against WDEF."  This was obviously a
gross error on my part.  My only excuse is that I don't have a copy of
Anti-Virus Kit that I can use for testing.  This is not a good excuse
- - I shouldn't have made the statement if I couldn't back it up.

1st Aid Software deserves a great deal of credit for having the only
virus prevention tool that was capable of catching WDEF.  Everybody
else failed, including Symantec's SAM, HJC's Virex, Gatekeeper, and
Vaccine.  I don't know about MainStay's AntiToxin - I don't have a
copy of that either (yet).

In the future I'll try very hard not to make claims that I can't back
up with solid evidence.

John Norstad         Northwestern University       [e-mail]

------------------------------

End of VIRUS-L Digest
*********************